Diễn giải kỹ thuật về Chainway: Làm thế nào các Dự án Layer2 Bitcoin Tận dụng các Khái niệm

Nâng cao2/9/2024, 7:03:24 AM
Bài viết này tiến hành phân tích sâu về giải pháp kỹ thuật của Chainway, tiết lộ rằng loại công nghệ được quảng cáo bởi cộng đồng dự án không phù hợp với định nghĩa chính thống của Rollup.

Giới thiệu:

Bối cảnh Bitcoin Layer2 hiện tại đang nhộn nhịp với các giải pháp công nghệ đa dạng hội tụ trong nồi nấu chảy của hệ sinh thái BTC. Với tốc độ lặp lại nhanh chóng trong lĩnh vực blockchain, nơi từ vựng và tiêu chuẩn chuyên nghiệp liên tục phát triển thông qua nghiên cứu, đổi mới và triển khai kỹ thuật, nhiều dự án sử dụng "tạo khái niệm" hoặc "quá giang khái niệm" để tạo sự khác biệt và chú ý, trở thành một quy tắc bất thành văn trong ngành. Ví dụ, một số dự án blockchain mô-đun ban đầu hoạt động trong hệ sinh thái Ethereum / Celestia đã nhảy vào nhóm "Bitcoin Layer2", tự gọi mình là "Rollups", mặc dù các giải pháp kỹ thuật của họ thường không đáp ứng các tiêu chuẩn Rollup. Tuy nhiên, thuật ngữ "Rollup" mang lại sự công nhận đáng kể, làm cho nó có lợi cho mục đích quảng cáo. Nhiều nhà điều hành dự án hoặc tự dán nhãn mạnh mẽ là Rollups hoặc phân nhánh khái niệm Rollup chính thống với các vòng loại mơ hồ, chẳng hạn như "Sovereign Rollup". Bóc tách các lớp của "XX Rollups" này, nhiều dự án về cơ bản dựa trên "xác thực phía máy khách" hoặc "sidechains", chỉ sử dụng khẩu hiệu "XX Rollup" để thuận tiện. Mặc dù chiến lược quảng cáo này là phổ biến, nhưng nó có xu hướng gây hiểu lầm, gây hại nhiều hơn là tốt cho những người tìm kiếm sự thật.


(Phương pháp này, được tóm tắt bởi Bộ trưởng Tuyên truyền của Đức Quốc xã Goebbels như là 'tuyên truyền dựa trên dối trá,' thường được quan sát trong số các nhà điều hành dự án.) Vậy làm sao chúng ta có thể phân biệt được hành vi 'đu bám khái niệm Rollup' như vậy? Có lẽ, bắt đầu từ nguyên tắc cơ bản, định nghĩa các loại dự án Layer2 khác nhau và cấp độ an ninh và chức năng của chúng dựa trên các tiêu chuẩn được chấp nhận rộng rãi ở phương Tây và trong ngành công nghiệp có thể mang lại sự rõ ràng. Điều quan trọng không nhất thiết là về giải pháp được chọn; điểm chính nằm ở việc cơ chế thiết kế của dự án đảm bảo an ninh và đáng tin cậy của mạng Layer2 và thực sự truyền cảm cho mạng BTC chính.

Bài viết này sẽ sử dụng Chainway, một dự án Bitcoin Layer2, như một nghiên cứu điển hình để mổ xẻ bản chất "xác thực phía máy khách" ẩn đằng sau khẩu hiệu "Rollup" của một số dự án. Chúng tôi mong muốn phân biệt rõ ràng giữa "Sovereign Rollup" và "client-side validation" và sự khác biệt đáng kể so với ZKRollups hoặc OPRollups tiêu chuẩn ngành dựa trên các hợp đồng thông minh. Điều này không có nghĩa là Sovereign Rollups hoặc xác thực phía máy khách kém hơn ZK Rollups về bảo mật và độ tin cậy; Tất cả phụ thuộc vào chi tiết thực hiện cụ thể của họ. Chainway, thường là Layer2 xác thực phía máy khách, đã đề xuất một kế hoạch giao dịch chống kiểm duyệt được kích hoạt trên BTC với xác thực ngoài chuỗi, sử dụng Bằng chứng ZK đệ quy tương tự như các bằng chứng được sử dụng bởi chuỗi công khai MINA, định vị nó trước nhiều dự án Bitcoin Layer2. Chúng tôi tin rằng nghiên cứu công nghệ của Chainway là có giá trị, cung cấp những hiểu biết quan trọng cho các nhà quan sát Bitcoin Layer2. (Hình ảnh quảng cáo của Chainway gọi nó là ZK Rollup, nhưng giải pháp cũ của nó là xác thực phía máy khách, với ZKR là một dự án khác của họ. Hiện tại, nó chưa đạt được sự đồng thuận của khách hàng ngoài chuỗi hoặc trao đổi tin nhắn đáng tin cậy.)

Văn bản chính: Chainway là một dự án Bitcoin Layer2 nổi tiếng trong cộng đồng phương Tây, thường được nhiều KOL gọi là "ZK Rollup", trong khi tài liệu kỹ thuật của nó định vị nó là "Sovereign Rollup". Gần đây, Chainway cũng đã công bố dự án mới của mình, Citrea, tuyên bố nó là một ZK Rollup dựa trên BitVM. Tuy nhiên, vì Citrea vẫn chưa nêu chi tiết giải pháp xác minh ZK dựa trên BitVM, bài viết này sẽ tập trung vào việc giải thích kỹ thuật các giải pháp trước đây của Chainway. Tóm lại, giải pháp kỹ thuật được tiết lộ công khai của Chainway liên quan đến việc xuất bản dữ liệu DA thông qua giao thức Ordinals, sử dụng BTC làm lớp DA và xuất bản chi tiết thay đổi trạng thái (State diff) + ZK Proof xác minh tính chính xác của các thay đổi trạng thái trên Layer1, tương đương với việc xuất bản dữ liệu giao dịch hoàn chỉnh, có thể kiểm chứng. Tuy nhiên, vì Layer1 không trực tiếp xác minh ZK Proofs, với việc xác minh được thực hiện bởi các máy khách / nút độc lập ngoài chuỗi và cơ sở mã hiện tại của Chainway đã không đạt được sự đồng thuận giữa các khách hàng ngoài chuỗi, cũng như không tuyên bố giải quyết vấn đề này trên phương tiện truyền thông xã hội, giải pháp kỹ thuật được tiết lộ công khai của Chainway về cơ bản thuộc về danh mục "xác thực phía máy khách", thậm chí giống như một giao thức được lập chỉ mục bằng mật mã hỗ trợ bắc cầu tài sản. Các phần sau đây sẽ giới thiệu cách triển khai kỹ thuật cụ thể của Chainway và phân tích mô hình bảo mật của nó.

Sovereign Rollup là gì: Dữ liệu Nhập cuộn (DA) Layer Publishing + Xác minh ngoại chuỗi

Trong tài liệu kỹ thuật của Chainway, khái niệm về Sovereign Rollup từ Celestia được sử dụng. Một Sovereign Rollup cơ bản khác biệt hoàn toàn so với khái niệm Rollup thông thường trong cộng đồng Ethereum và ngành công nghiệp rộng lớn (Rollup hợp đồng thông minh). Vậy, cấu trúc của một Sovereign Rollup chính xác là gì?

Về bản chất, Sovereign Rollup dựa trên Bitcoin có phần giống với "nhóm khách hàng ngoài chuỗi / sidechain xuất bản dữ liệu DA trên blockchain BTC". Đặc điểm chính của nó là nó không yêu cầu các hợp đồng thông minh trên Lớp 1 để xác minh các chuyển đổi trạng thái / hành động chuỗi chéo cho Lớp 2. Về cơ bản, nó sử dụng BTC làm lớp DA và mô hình bảo mật của nó phần lớn tương tự như "xác thực phía máy khách". Tất nhiên, một số giải pháp Sovereign Rollup an toàn hơn dựa vào lớp thanh toán của bên thứ ba ngoài chuỗi Bitcoin (tương tự như sidechain) để thực hiện xác minh chuyển đổi trạng thái. Ngoài ra, giữa các khách hàng độc lập / nút đầy đủ khác nhau, tồn tại một mức độ đồng thuận hoặc thông điệp đáng tin cậy để đạt được "thỏa thuận" về một số hành động gây tranh cãi nhất định. Tuy nhiên, một số dự án Sovereign Rollup hoàn toàn dựa trên "xác thực phía máy khách", thiếu bất kỳ thông điệp đáng tin cậy nào được truyền giữa các máy khách / nút độc lập.


Để hiểu rõ hơn về khái niệm độc đáo của "Sovereign Rollup", thật hữu ích khi so sánh nó với đối tác của nó, hợp đồng thông minh Rollup. Trên Ethereum, các giải pháp Lớp 2 chủ yếu là các bản tổng hợp hợp đồng thông minh, chẳng hạn như Arbitrum và StarkNet. Cấu trúc của một hợp đồng thông minh Rollup có thể được hình dung trong sơ đồ sau:

(Hãy tưởng tượng một biểu đồ ở đây)


Trong sơ đồ, chúng ta có thể thấy một số thuật ngữ liên quan đến câu chuyện về mô-đun blockchain, được giải thích như sau:

  • Lớp thực thi: Thực thi các giao dịch người dùng, cập nhật trạng thái blockchain, và gửi dữ liệu đến lớp DA và lớp thanh toán.

  • Tầng giải quyết: Xác minh các chuyển đổi trạng thái từ lớp thực thi, giải quyết tranh chấp (như chứng cứ gian lận), và cung cấp một mô-đun cầu nối cho việc xử lý tài sản cầu nối L1-L2.

  • Lớp Khả dụng Dữ liệu (DA): Hành vi như một bảng tin lớn, nhận dữ liệu chuyển trạng thái được gửi bởi lớp thực thi và cung cấp dữ liệu này một cách không cần tin cậy cho bất kỳ ai.

  • Lớp đồng thuận: Đảm bảo sự hoàn thiện của việc sắp xếp giao dịch. Chức năng của nó có vẻ gần giống với lớp DA (phương pháp tiếp cận tầng blockchain modul của cộng đồng Ethereum không bao gồm tầng đồng thuận).

    Từ kiến trúc của các hợp đồng thông minh Rollups, chúng ta thấy rằng Ethereum đảm nhận vai trò của ba lớp cuối cùng, ngoài lớp thực thi. Một biểu đồ khác có thể cung cấp cái nhìn chi tiết hơn về các vai trò mà Ethereum đóng trong các hợp đồng thông minh Rollups.

    Ngược lại, Sovereign Rollups khác biệt đáng kể ở chỗ chúng phân tán một số trách nhiệm này ra khỏi một chuỗi khối đơn như Ethereum. Cụ thể, chúng không phụ thuộc vào hợp đồng thông minh trên lớp cơ bản (Lớp 1) để xác minh các chuyển đổi trạng thái hoặc xử lý tranh chấp. Thay vào đó, những nhiệm vụ này được quản lý bởi các khách hàng ngoại tuyến hoặc thông qua một lớp giải quyết của bên thứ ba, nhấn mạnh một cách tiếp cận khác cho việc đạt được khả năng mở rộng và bảo mật trong hệ thống chuỗi khối.

Các hợp đồng Rollup trên Ethereum nhận được bằng chứng tính hợp lệ hoặc bằng chứng gian lận để xác minh tính hợp lệ của các chuyển đổi trạng thái Layer 2. Đáng chú ý rằng các hợp đồng thông minh Rollup hoạt động như các thực thể lớp giải quyết trong kiến trúc blockchain modul. Các hợp đồng lớp giải quyết thường bao gồm các mô-đun cầu nối để xử lý tài sản được cầu nối từ Ethereum sang Layer 2. Đối với Khả dụng Dữ liệu (DA), các hợp đồng lớp giải quyết có thể yêu cầu Sequencer đăng tải các thông tin giao dịch/thay đổi trạng thái mới nhất trên chuỗi. Mà không cần đăng tải DA trên chuỗi, thì không thể cập nhật thành công trạng thái L2 được ghi lại trong các hợp đồng Rollup.


(ZK Rollup hoặc Optimistic Rollup có thể bắt buộc dữ liệu DA được đăng trên chuỗi; nếu không có, trạng thái được ghi lại trong lớp giải quyết không thể được cập nhật.) Từ việc phân tích mô hình bảo mật và các chỉ số rủi ro của các giải pháp Lớp 2 của Bitcoin/Ethereum với lý thuyết thùng, rõ ràng rằng Rollups hợp đồng thông minh phụ thuộc nặng vào các hợp đồng thông minh của Lớp 1. Đối với Lớp 1 như BTC, gặp khó khăn trong việc hỗ trợ logic kinh doanh phức tạp, việc xây dựng một Lớp 2 phù hợp với Ethereum Rollups về cơ bản là không thể. Các giải pháp Sovereign Rollup, tuy nhiên, không đòi hỏi hợp đồng trên Lớp 1 cho việc xác minh/truyền dữ liệu. Kiến ​​trúc của họ như sau: (Ở đây, mô tả về kiến trúc đã bị thiếu, ngụ ý rằng có thể dự định bao gồm minh họa hoặc chi tiết thêm nhưng không được cung cấp trong văn bản.)


Trong Rollups chủ quyền, các nút ngoài lớp Data Availability (DA) phục vụ như các thực thể cho việc thực hiện giao dịch và các hoạt động thanh toán, cung cấp một mức độ tự do cao hơn. Luồng công việc diễn ra như sau:

Các nút trong lớp thực thi của Rollup có chủ quyền gửi dữ liệu giao dịch / chi tiết thay đổi trạng thái đến lớp DA, trong khi lớp / máy khách thanh toán cố gắng lấy và xác minh dữ liệu. Điều quan trọng cần lưu ý là vì mô-đun lớp giải quyết không nằm trên Lớp 1, về lý thuyết, các Bản tổng hợp có chủ quyền không thể đạt được các cầu nối có bảo mật tương đương với Lớp 1. Họ thường dựa vào cầu công chứng hoặc các giải pháp bắc cầu của bên thứ ba. Hiện tại, việc thực hiện các chương trình xác minh Rollup / khách hàng có chủ quyền tương đối đơn giản, chỉ yêu cầu xuất bản dữ liệu trên chuỗi Bitcoin (BTC) bằng giao thức tương tự như Ordinals. Đối với xác minh và đồng thuận ngoài chuỗi, có rất nhiều tính linh hoạt. Trên thực tế, nhiều sidechain chỉ đơn giản là xuất bản dữ liệu DA trên chuỗi BTC, về cơ bản trở thành "Bản tổng hợp có chủ quyền dựa trên BTC", mặc dù tính bảo mật cụ thể là nghi vấn. Tuy nhiên, vấn đề là thông lượng dữ liệu của Bitcoin cực kỳ thấp, với tối đa 4MB mỗi khối và thời gian khối trung bình là 10 phút, tương đương với thông lượng dữ liệu chỉ 6KB / s. Các giải pháp lớp 2 tuyên bố là có chủ quyền Bản tổng hợp có thể không thể xuất bản tất cả dữ liệu DA trên chuỗi BTC, do đó họ có thể chọn các phương pháp thay thế, chẳng hạn như xuất bản dữ liệu DA ngoài chuỗi và lưu trữ dữ liệu băm trên chuỗi BTC như một hình thức "cam kết" hoặc tìm cách nén dữ liệu DA cao (ví dụ: sử dụng State diff + ZK Proof như tuyên bố của Chainway). Rõ ràng, chế độ này không phù hợp với định nghĩa của "sovereign Rollup" hoặc một Rollup thích hợp, đại diện cho một biến thể có vấn đề về bảo mật. Chúng tôi dự đoán rằng hầu hết các dự án Lớp 2 mang biểu ngữ "Tổng hợp" cuối cùng sẽ không xuất bản tất cả dữ liệu DA trên chuỗi BTC, vì vậy các giải pháp thực tế của họ có thể sẽ không khớp với tuyên bố "ZK Rollup" hoặc "OP Rollup" được đưa ra trong whitepaper của họ.

Cuối cùng, hãy tóm tắt ngắn gọn các khác biệt giữa Sovereign Rollups và Smart Contract Rollups:

  1. Khả năng nâng cấp:Các phiên bản cập nhật của hợp đồng thông minh Rollups liên quan đến việc cập nhật các hợp đồng thông minh, yêu cầu đội ngũ phát triển sử dụng các hợp đồng có thể nâng cấp. Loại cập nhật hợp đồng thông minh này thường được kiểm soát bởi đội ngũ phát triển Rollup thông qua nhiều chữ ký. Ngược lại, các quy tắc cập nhật cho các Rollups chủ quyền tương tự như các bifurcation mềm và cứng của blockchain truyền thống, nơi các nút có thể chọn cập nhật phiên bản một cách độc lập, và các khách hàng khác nhau có thể chọn xem có chấp nhận việc nâng cấp hay không. Từ góc độ này, Rollups chủ quyền vượt trội so với Rollups hợp đồng thông minh về khả năng nâng cấp.

  2. Cầu:Trong điều kiện lý tưởng, các cầu cho các Rollups hợp đồng thông minh tuân theo sự tin cậy tối thiểu, nhưng khả năng nâng cấp của các hợp đồng có thể ảnh hưởng đến tính bảo mật của chúng. Theo kế hoạch Rollup chủ quyền, các nhà phát triển cần xây dựng các thành phần cầu nối trên chuỗi Layer 1 một cách tự lập, và các cầu được xây dựng có thể tin cậy ít hơn so với các cầu hợp đồng thông minh.

Cấu trúc DA của BTC

Trong đoạn văn trên, chúng tôi đã đề cập rằng để triển khai một Rollup chủ quyền dựa trên BTC, điều quan trọng nằm ở việc sử dụng giao thức Ordinals để làm cho BTC phục vụ như lớp Data Availability (DA). Chainway đã áp dụng giải pháp này.

Chúng ta có thể xem xét một bản ghi dữ liệu DA từ trình tự Chainway, với mã giao dịch là:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, được minh họa như sau:


Kịch bản giao dịch này mượn cách tiếp cận của Giao thức Ordinals sử dụng OP_0 OP_IF để ghi dữ liệu vào việc viết dữ liệu DA (Data Availability) của Rollup lên chuỗi BTC. Điều này liên quan đến việc công bố các thay đổi trạng thái và ZK Proofs, tương đương về mặt bảo mật với việc công bố dữ liệu giao dịch ban đầu nhưng cho phép giảm kích thước dữ liệu đáng kể. Ngoài dữ liệu DA, người sắp xếp cũng ghi một số dữ liệu xác thực vào giao dịch, với điểm quan trọng nhất là người sắp xếp Rollup ký dữ liệu DA bằng khóa riêng để đảm bảo việc nộp hồ sơ đến từ người sắp xếp. Quan trọng nhấn rằng bất kỳ giao dịch nào liên quan đến việc nộp dữ liệu DA đều có 16 số không nhị phân ở cuối băm giao dịch (tức là, hai byte liên tiếp là không). Hạn chế này có thể thấy trong mã:

Trong biểu đồ giao dịch ví dụ đã đề cập trước đó, số ngẫu nhiên "b715" được sử dụng để điều chỉnh giá trị băm của giao dịch sao cho đuôi của nó mang 16 số không cụ thể. Nguyên tắc này tương tự như khai thác Bitcoin, trong đó một số ngẫu nhiên nonce được thêm vào để làm cho các bit N đứng đầu của hàm băm trở thành tất cả các số không, đáp ứng các điều kiện ràng buộc cụ thể. Thiết kế này nhằm mục đích đơn giản hóa khó khăn trong việc lấy dữ liệu DA (Data Availability). Khi bất kỳ nút Layer2 nào muốn truy cập dữ liệu DA, nó chỉ cần quét khối BTC (Bitcoin) cho tất cả các giao dịch được đặt để kết thúc bằng 16 số không, phân biệt hiệu quả các giao dịch được khởi tạo bởi trình phân loại Chainway khi gửi dữ liệu từ các giao dịch khác trên blockchain Bitcoin. Trong văn bản sau, các giao dịch như vậy chứa dữ liệu DA và đáp ứng yêu cầu kết thúc bằng 16 số 0 được gọi là "giao dịch tiêu chuẩn Chainway". Trọng tâm của bài viết này là về cách Chainway đạt được khả năng chống kiểm duyệt. Vì trình phân loại Lớp 2 có thể cố tình từ chối yêu cầu giao dịch từ một người dùng cụ thể, nên phải sử dụng một sơ đồ đặc biệt để cho phép người dùng bắt đầu các giao dịch chống lại kiểm duyệt. Để giải quyết vấn đề này, Chainway cho phép người dùng khởi chạy "Giao dịch bắt buộc". Khi người dùng gửi khai báo giao dịch này trong khối BTC, trình phân loại Chainway phải xử lý yêu cầu giao dịch này trên Lớp 2; Nếu không, nó sẽ không thể tạo ra một khối bình thường hoặc khối được tạo ra sẽ không được nhận ra bởi các máy khách ngoài chuỗi. Cấu trúc tham số của giao dịch bắt buộc như sau:

Giao dịch này sẽ được gửi đến blockchain Bitcoin dưới dạng “Giao dịch Đặc tả Chuỗi,” với mã hash giao dịch kết thúc bằng 16 số không. Người sắp xếp ChainWay, khi tạo các khối L2, phải bao gồm “Giao dịch Đặc tả Tầng 2” đã được tiết lộ trên blockchain BTC nhưng chưa được ghi vào sổ cái L2, và tổng hợp chúng thành Mạng Merkle, viết gốc Merkle của nó vào tiêu đề khối L2. Khi một người dùng khởi tạo một giao dịch cưỡng chế trực tiếp trên blockchain BTC, người sắp xếp phải xử lý nó; nếu không, nó không thể tạo ra khối hợp lệ kế tiếp. Khách hàng Chainway ngoài chuỗi BTC có thể xác minh chứng minh ZK trước để xác định tính hợp lệ của khối L2 được gửi bởi người sắp xếp, kiểm tra gốc Merkle của tiêu đề khối L2, và xem xét liệu người sắp xếp đã bao gồm yêu cầu giao dịch cưỡng chế một cách trung thực. Quy trình làm việc có thể tham khảo biểu đồ luồng dưới đây. Lưu ý rằng, do hạn chế không gian, biểu đồ dưới đây thiếu một sự xét đoán điều kiện trong verify_relevant_tx_list:

Tóm lại, máy khách / nút Chainway đồng bộ hóa với các khối mạng chính BTC và quét "dữ liệu DA" được xuất bản bởi trình phân loại Chainway từ chúng. Nó xác minh rằng những dữ liệu này được xuất bản bởi trình phân loại được chỉ định và thực sự chứa tất cả các "giao dịch tiêu chuẩn Chainway" được gửi đến chuỗi BTC. Rõ ràng là miễn là người dùng có thể xây dựng một giao dịch đáp ứng các tiêu chí được chỉ định là "giao dịch tiêu chuẩn" và gửi nó đến chuỗi BTC, giao dịch này cuối cùng sẽ được đưa vào sổ cái L2 cục bộ của khách hàng Chainway. Nếu không, khối L2 được phát hành bởi trình sắp xếp Chainway sẽ bị máy khách từ chối. Nếu kết hợp với truyền tin nhắn cảnh báo / đồng thuận ngoài chuỗi đáng tin cậy, kế hoạch giao dịch chống kiểm duyệt của Chainway tiếp cận phương pháp chống kiểm duyệt lý tưởng của Rollups có chủ quyền. Ví dụ: một số giải pháp Rollup có chủ quyền đã tuyên bố rõ ràng rằng trong trường hợp chặn không hợp lệ, các thông báo cảnh báo Cảnh báo sẽ được phát giữa các máy khách ngoài chuỗi để tăng cường bảo mật, đặc biệt là cho phép các máy khách nhẹ không thể đồng bộ hóa dữ liệu DA hoàn chỉnh biết về sự bất thường của mạng. Nếu một khối không trung thực bao gồm "các giao dịch bắt buộc", rõ ràng nó sẽ kích hoạt một chương trình phát sóng cảnh báo ngoài chuỗi. Tuy nhiên, Chainway vẫn chưa triển khai khía cạnh này (ít nhất là các tài liệu và kho lưu trữ mã được công bố hiện tại cho thấy họ chưa thực hiện việc triển khai kỹ thuật của phần này).

Tài liệu tham khảo: Các nhà nghiên cứu Celestia phân tích 6 loại biến thể Rollup: Sequencer = Aggregator + Header Generator. Ngay cả với sự đồng thuận đạt được giữa các khách hàng / nút ngoài chuỗi, hiệu quả chống kiểm duyệt của "giao dịch bắt buộc" của Chainway không mạnh mẽ như các bản tổng hợp hợp đồng thông minh như Arbitrum, bởi vì Arbitrum One cuối cùng sẽ đảm bảo "giao dịch bắt buộc" được đưa vào sổ cái Layer2 thông qua các hợp đồng trên Layer1, kế thừa đầy đủ các đặc tính chống kiểm duyệt của Layer1. Sovereign Rollups rõ ràng không thể phù hợp với các bản tổng hợp hợp đồng thông minh ở khía cạnh này, vì hiệu quả chống kiểm duyệt của chúng cuối cùng phụ thuộc vào các thành phần ngoài chuỗi. Điều này cũng xác định rằng cách tiếp cận của các chương trình "Sovereign Rollups" và "client verification" về cơ bản không thể kế thừa đầy đủ các thuộc tính chống kiểm duyệt của Layer1, như Arbitrum One, Loopring, dydx và Degate, bởi vì liệu các giao dịch bắt buộc có thể được đưa vào sổ cái Layer2 hay không phụ thuộc vào quyết định của các thực thể ngoài chuỗi Layer2, không liên quan đến chính Layer1. Rõ ràng, cách tiếp cận của Chainway, chỉ dựa vào quyết định của các khách hàng ngoài chuỗi, chỉ kế thừa độ tin cậy DA của Layer1, chứ không phải các đặc tính chống kiểm duyệt đầy đủ của nó. Tương tự như các bằng chứng ZK đệ quy của MINA.

Trong phần này, chúng tôi sẽ giới thiệu thêm các thành phần khác của Chainway, ngoài việc sử dụng BTC như là lớp DA, cũng thực hiện các chứng minh ZK đệ quy tương tự như MINA. Cấu trúc tổng thể của nó được minh họa trong sơ đồ sau:


Trình phân loại trong mạng Chainway, sau khi xử lý các giao dịch của người dùng, tạo ra bằng chứng ZK (Zero-Knowledge) cuối cùng cùng với các chi tiết về thay đổi trạng thái (trạng thái khác biệt) cho các tài khoản khác nhau và xuất bản chúng trên blockchain Bitcoin (BTC). Các nút đầy đủ sẽ đồng bộ hóa tất cả dữ liệu lịch sử của Chainway được công bố trên blockchain BTC. Mỗi bằng chứng ZK không chỉ phải chứng minh quá trình chuyển đổi trạng thái của khối hiện tại mà còn đảm bảo tính hợp lệ của bằng chứng ZK của khối trước đó. Dựa trên sơ đồ này, chúng ta có thể thấy rằng mỗi khi một bằng chứng mới được tạo ra, về cơ bản nó xác nhận chứng minh trước đó theo cách đệ quy và bằng chứng ZK mới nhất có thể đảm bảo tính hợp lệ của tất cả các bằng chứng ZK bắt đầu từ khối gốc. Thiết kế này tương tự như của MINA. Khi một "light client" chỉ đồng bộ hóa các tiêu đề khối, còn được gọi là light node, tham gia mạng, nó chỉ cần xác minh tính hợp lệ của ZK Proof mới nhất được tiết lộ trên blockchain BTC để xác nhận rằng toàn bộ dữ liệu lịch sử của chuỗi và tất cả các chuyển đổi trạng thái là hợp lệ. Nếu trình phân loại hành động độc hại, cố ý từ chối chấp nhận các giao dịch bắt buộc hoặc không sử dụng bằng chứng ZK trước đó để chứng minh đệ quy, thì khách hàng không thể chấp nhận bằng chứng ZK mới được tạo (ngay cả khi được tạo, nó không được công nhận), như thể hiện trong sơ đồ dưới đây:

Tóm tắt

Như được tóm tắt ở đầu bài viết này, Chainway về cơ bản là một lược đồ Rollup/client chủ quyền sử dụng BTC như một lớp Data Availability (DA). Để tăng cường khả năng chống kiểm duyệt của Rollup, Chainway giới thiệu khái niệm giao dịch bắt buộc. Trong khi đó, Chainway sử dụng công nghệ chứng minh ZK đệ quy, cho phép các nút mới tin tưởng vào kết quả của sequencer hơn và xác minh tính chính xác của dữ liệu lịch sử của toàn bộ chuỗi bất kỳ lúc nào. Vấn đề hiện tại của Chainway nằm ở cơ chế tin cậy của cầu nối qua chuỗi của nó. Bởi vì nó áp dụng phương pháp Rollup chủ quyền mà không chỉ rõ cách nó dự định giải quyết các chi tiết kỹ thuật trong giải pháp cầu nối qua chuỗi của mình, việc đánh giá tính an toàn cuối cùng của nó là khó khăn.

Hôm nay, bằng cách đào sâu vào giải pháp kỹ thuật của Chainway, chúng tôi phát hiện rằng loại công nghệ được quảng bá bởi cộng đồng dự án không phải là một Rollup trong ý nghĩa chủ yếu. Xét đến sự hiện diện của hàng chục dự án Bitcoin Layer2 (có thể lên tới hàng trăm trong nửa năm), để giảm chi phí nhận thức về thuật ngữ kỹ thuật, chúng tôi sẽ tiếp tục tiến hành nghiên cứu sâu rộng về phân loại các giải pháp Layer2 và tiêu chuẩn về bảo mật, đầy đủ chức năng và đánh giá. Hãy theo dõi!

Disclaimer:

  1. Bài viết này được in lại từ [Web3 của Gate]. Tất cả bản quyền thuộc về tác giả gốc [Shew & Faust, web3 của các chuyên gia]. Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ với Gate Học và họ sẽ xử lý kịp thời.
  2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không đưa ra bất kỳ lời khuyên đầu tư nào.
  3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu rõ, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.

Diễn giải kỹ thuật về Chainway: Làm thế nào các Dự án Layer2 Bitcoin Tận dụng các Khái niệm

Nâng cao2/9/2024, 7:03:24 AM
Bài viết này tiến hành phân tích sâu về giải pháp kỹ thuật của Chainway, tiết lộ rằng loại công nghệ được quảng cáo bởi cộng đồng dự án không phù hợp với định nghĩa chính thống của Rollup.

Giới thiệu:

Bối cảnh Bitcoin Layer2 hiện tại đang nhộn nhịp với các giải pháp công nghệ đa dạng hội tụ trong nồi nấu chảy của hệ sinh thái BTC. Với tốc độ lặp lại nhanh chóng trong lĩnh vực blockchain, nơi từ vựng và tiêu chuẩn chuyên nghiệp liên tục phát triển thông qua nghiên cứu, đổi mới và triển khai kỹ thuật, nhiều dự án sử dụng "tạo khái niệm" hoặc "quá giang khái niệm" để tạo sự khác biệt và chú ý, trở thành một quy tắc bất thành văn trong ngành. Ví dụ, một số dự án blockchain mô-đun ban đầu hoạt động trong hệ sinh thái Ethereum / Celestia đã nhảy vào nhóm "Bitcoin Layer2", tự gọi mình là "Rollups", mặc dù các giải pháp kỹ thuật của họ thường không đáp ứng các tiêu chuẩn Rollup. Tuy nhiên, thuật ngữ "Rollup" mang lại sự công nhận đáng kể, làm cho nó có lợi cho mục đích quảng cáo. Nhiều nhà điều hành dự án hoặc tự dán nhãn mạnh mẽ là Rollups hoặc phân nhánh khái niệm Rollup chính thống với các vòng loại mơ hồ, chẳng hạn như "Sovereign Rollup". Bóc tách các lớp của "XX Rollups" này, nhiều dự án về cơ bản dựa trên "xác thực phía máy khách" hoặc "sidechains", chỉ sử dụng khẩu hiệu "XX Rollup" để thuận tiện. Mặc dù chiến lược quảng cáo này là phổ biến, nhưng nó có xu hướng gây hiểu lầm, gây hại nhiều hơn là tốt cho những người tìm kiếm sự thật.


(Phương pháp này, được tóm tắt bởi Bộ trưởng Tuyên truyền của Đức Quốc xã Goebbels như là 'tuyên truyền dựa trên dối trá,' thường được quan sát trong số các nhà điều hành dự án.) Vậy làm sao chúng ta có thể phân biệt được hành vi 'đu bám khái niệm Rollup' như vậy? Có lẽ, bắt đầu từ nguyên tắc cơ bản, định nghĩa các loại dự án Layer2 khác nhau và cấp độ an ninh và chức năng của chúng dựa trên các tiêu chuẩn được chấp nhận rộng rãi ở phương Tây và trong ngành công nghiệp có thể mang lại sự rõ ràng. Điều quan trọng không nhất thiết là về giải pháp được chọn; điểm chính nằm ở việc cơ chế thiết kế của dự án đảm bảo an ninh và đáng tin cậy của mạng Layer2 và thực sự truyền cảm cho mạng BTC chính.

Bài viết này sẽ sử dụng Chainway, một dự án Bitcoin Layer2, như một nghiên cứu điển hình để mổ xẻ bản chất "xác thực phía máy khách" ẩn đằng sau khẩu hiệu "Rollup" của một số dự án. Chúng tôi mong muốn phân biệt rõ ràng giữa "Sovereign Rollup" và "client-side validation" và sự khác biệt đáng kể so với ZKRollups hoặc OPRollups tiêu chuẩn ngành dựa trên các hợp đồng thông minh. Điều này không có nghĩa là Sovereign Rollups hoặc xác thực phía máy khách kém hơn ZK Rollups về bảo mật và độ tin cậy; Tất cả phụ thuộc vào chi tiết thực hiện cụ thể của họ. Chainway, thường là Layer2 xác thực phía máy khách, đã đề xuất một kế hoạch giao dịch chống kiểm duyệt được kích hoạt trên BTC với xác thực ngoài chuỗi, sử dụng Bằng chứng ZK đệ quy tương tự như các bằng chứng được sử dụng bởi chuỗi công khai MINA, định vị nó trước nhiều dự án Bitcoin Layer2. Chúng tôi tin rằng nghiên cứu công nghệ của Chainway là có giá trị, cung cấp những hiểu biết quan trọng cho các nhà quan sát Bitcoin Layer2. (Hình ảnh quảng cáo của Chainway gọi nó là ZK Rollup, nhưng giải pháp cũ của nó là xác thực phía máy khách, với ZKR là một dự án khác của họ. Hiện tại, nó chưa đạt được sự đồng thuận của khách hàng ngoài chuỗi hoặc trao đổi tin nhắn đáng tin cậy.)

Văn bản chính: Chainway là một dự án Bitcoin Layer2 nổi tiếng trong cộng đồng phương Tây, thường được nhiều KOL gọi là "ZK Rollup", trong khi tài liệu kỹ thuật của nó định vị nó là "Sovereign Rollup". Gần đây, Chainway cũng đã công bố dự án mới của mình, Citrea, tuyên bố nó là một ZK Rollup dựa trên BitVM. Tuy nhiên, vì Citrea vẫn chưa nêu chi tiết giải pháp xác minh ZK dựa trên BitVM, bài viết này sẽ tập trung vào việc giải thích kỹ thuật các giải pháp trước đây của Chainway. Tóm lại, giải pháp kỹ thuật được tiết lộ công khai của Chainway liên quan đến việc xuất bản dữ liệu DA thông qua giao thức Ordinals, sử dụng BTC làm lớp DA và xuất bản chi tiết thay đổi trạng thái (State diff) + ZK Proof xác minh tính chính xác của các thay đổi trạng thái trên Layer1, tương đương với việc xuất bản dữ liệu giao dịch hoàn chỉnh, có thể kiểm chứng. Tuy nhiên, vì Layer1 không trực tiếp xác minh ZK Proofs, với việc xác minh được thực hiện bởi các máy khách / nút độc lập ngoài chuỗi và cơ sở mã hiện tại của Chainway đã không đạt được sự đồng thuận giữa các khách hàng ngoài chuỗi, cũng như không tuyên bố giải quyết vấn đề này trên phương tiện truyền thông xã hội, giải pháp kỹ thuật được tiết lộ công khai của Chainway về cơ bản thuộc về danh mục "xác thực phía máy khách", thậm chí giống như một giao thức được lập chỉ mục bằng mật mã hỗ trợ bắc cầu tài sản. Các phần sau đây sẽ giới thiệu cách triển khai kỹ thuật cụ thể của Chainway và phân tích mô hình bảo mật của nó.

Sovereign Rollup là gì: Dữ liệu Nhập cuộn (DA) Layer Publishing + Xác minh ngoại chuỗi

Trong tài liệu kỹ thuật của Chainway, khái niệm về Sovereign Rollup từ Celestia được sử dụng. Một Sovereign Rollup cơ bản khác biệt hoàn toàn so với khái niệm Rollup thông thường trong cộng đồng Ethereum và ngành công nghiệp rộng lớn (Rollup hợp đồng thông minh). Vậy, cấu trúc của một Sovereign Rollup chính xác là gì?

Về bản chất, Sovereign Rollup dựa trên Bitcoin có phần giống với "nhóm khách hàng ngoài chuỗi / sidechain xuất bản dữ liệu DA trên blockchain BTC". Đặc điểm chính của nó là nó không yêu cầu các hợp đồng thông minh trên Lớp 1 để xác minh các chuyển đổi trạng thái / hành động chuỗi chéo cho Lớp 2. Về cơ bản, nó sử dụng BTC làm lớp DA và mô hình bảo mật của nó phần lớn tương tự như "xác thực phía máy khách". Tất nhiên, một số giải pháp Sovereign Rollup an toàn hơn dựa vào lớp thanh toán của bên thứ ba ngoài chuỗi Bitcoin (tương tự như sidechain) để thực hiện xác minh chuyển đổi trạng thái. Ngoài ra, giữa các khách hàng độc lập / nút đầy đủ khác nhau, tồn tại một mức độ đồng thuận hoặc thông điệp đáng tin cậy để đạt được "thỏa thuận" về một số hành động gây tranh cãi nhất định. Tuy nhiên, một số dự án Sovereign Rollup hoàn toàn dựa trên "xác thực phía máy khách", thiếu bất kỳ thông điệp đáng tin cậy nào được truyền giữa các máy khách / nút độc lập.


Để hiểu rõ hơn về khái niệm độc đáo của "Sovereign Rollup", thật hữu ích khi so sánh nó với đối tác của nó, hợp đồng thông minh Rollup. Trên Ethereum, các giải pháp Lớp 2 chủ yếu là các bản tổng hợp hợp đồng thông minh, chẳng hạn như Arbitrum và StarkNet. Cấu trúc của một hợp đồng thông minh Rollup có thể được hình dung trong sơ đồ sau:

(Hãy tưởng tượng một biểu đồ ở đây)


Trong sơ đồ, chúng ta có thể thấy một số thuật ngữ liên quan đến câu chuyện về mô-đun blockchain, được giải thích như sau:

  • Lớp thực thi: Thực thi các giao dịch người dùng, cập nhật trạng thái blockchain, và gửi dữ liệu đến lớp DA và lớp thanh toán.

  • Tầng giải quyết: Xác minh các chuyển đổi trạng thái từ lớp thực thi, giải quyết tranh chấp (như chứng cứ gian lận), và cung cấp một mô-đun cầu nối cho việc xử lý tài sản cầu nối L1-L2.

  • Lớp Khả dụng Dữ liệu (DA): Hành vi như một bảng tin lớn, nhận dữ liệu chuyển trạng thái được gửi bởi lớp thực thi và cung cấp dữ liệu này một cách không cần tin cậy cho bất kỳ ai.

  • Lớp đồng thuận: Đảm bảo sự hoàn thiện của việc sắp xếp giao dịch. Chức năng của nó có vẻ gần giống với lớp DA (phương pháp tiếp cận tầng blockchain modul của cộng đồng Ethereum không bao gồm tầng đồng thuận).

    Từ kiến trúc của các hợp đồng thông minh Rollups, chúng ta thấy rằng Ethereum đảm nhận vai trò của ba lớp cuối cùng, ngoài lớp thực thi. Một biểu đồ khác có thể cung cấp cái nhìn chi tiết hơn về các vai trò mà Ethereum đóng trong các hợp đồng thông minh Rollups.

    Ngược lại, Sovereign Rollups khác biệt đáng kể ở chỗ chúng phân tán một số trách nhiệm này ra khỏi một chuỗi khối đơn như Ethereum. Cụ thể, chúng không phụ thuộc vào hợp đồng thông minh trên lớp cơ bản (Lớp 1) để xác minh các chuyển đổi trạng thái hoặc xử lý tranh chấp. Thay vào đó, những nhiệm vụ này được quản lý bởi các khách hàng ngoại tuyến hoặc thông qua một lớp giải quyết của bên thứ ba, nhấn mạnh một cách tiếp cận khác cho việc đạt được khả năng mở rộng và bảo mật trong hệ thống chuỗi khối.

Các hợp đồng Rollup trên Ethereum nhận được bằng chứng tính hợp lệ hoặc bằng chứng gian lận để xác minh tính hợp lệ của các chuyển đổi trạng thái Layer 2. Đáng chú ý rằng các hợp đồng thông minh Rollup hoạt động như các thực thể lớp giải quyết trong kiến trúc blockchain modul. Các hợp đồng lớp giải quyết thường bao gồm các mô-đun cầu nối để xử lý tài sản được cầu nối từ Ethereum sang Layer 2. Đối với Khả dụng Dữ liệu (DA), các hợp đồng lớp giải quyết có thể yêu cầu Sequencer đăng tải các thông tin giao dịch/thay đổi trạng thái mới nhất trên chuỗi. Mà không cần đăng tải DA trên chuỗi, thì không thể cập nhật thành công trạng thái L2 được ghi lại trong các hợp đồng Rollup.


(ZK Rollup hoặc Optimistic Rollup có thể bắt buộc dữ liệu DA được đăng trên chuỗi; nếu không có, trạng thái được ghi lại trong lớp giải quyết không thể được cập nhật.) Từ việc phân tích mô hình bảo mật và các chỉ số rủi ro của các giải pháp Lớp 2 của Bitcoin/Ethereum với lý thuyết thùng, rõ ràng rằng Rollups hợp đồng thông minh phụ thuộc nặng vào các hợp đồng thông minh của Lớp 1. Đối với Lớp 1 như BTC, gặp khó khăn trong việc hỗ trợ logic kinh doanh phức tạp, việc xây dựng một Lớp 2 phù hợp với Ethereum Rollups về cơ bản là không thể. Các giải pháp Sovereign Rollup, tuy nhiên, không đòi hỏi hợp đồng trên Lớp 1 cho việc xác minh/truyền dữ liệu. Kiến ​​trúc của họ như sau: (Ở đây, mô tả về kiến trúc đã bị thiếu, ngụ ý rằng có thể dự định bao gồm minh họa hoặc chi tiết thêm nhưng không được cung cấp trong văn bản.)


Trong Rollups chủ quyền, các nút ngoài lớp Data Availability (DA) phục vụ như các thực thể cho việc thực hiện giao dịch và các hoạt động thanh toán, cung cấp một mức độ tự do cao hơn. Luồng công việc diễn ra như sau:

Các nút trong lớp thực thi của Rollup có chủ quyền gửi dữ liệu giao dịch / chi tiết thay đổi trạng thái đến lớp DA, trong khi lớp / máy khách thanh toán cố gắng lấy và xác minh dữ liệu. Điều quan trọng cần lưu ý là vì mô-đun lớp giải quyết không nằm trên Lớp 1, về lý thuyết, các Bản tổng hợp có chủ quyền không thể đạt được các cầu nối có bảo mật tương đương với Lớp 1. Họ thường dựa vào cầu công chứng hoặc các giải pháp bắc cầu của bên thứ ba. Hiện tại, việc thực hiện các chương trình xác minh Rollup / khách hàng có chủ quyền tương đối đơn giản, chỉ yêu cầu xuất bản dữ liệu trên chuỗi Bitcoin (BTC) bằng giao thức tương tự như Ordinals. Đối với xác minh và đồng thuận ngoài chuỗi, có rất nhiều tính linh hoạt. Trên thực tế, nhiều sidechain chỉ đơn giản là xuất bản dữ liệu DA trên chuỗi BTC, về cơ bản trở thành "Bản tổng hợp có chủ quyền dựa trên BTC", mặc dù tính bảo mật cụ thể là nghi vấn. Tuy nhiên, vấn đề là thông lượng dữ liệu của Bitcoin cực kỳ thấp, với tối đa 4MB mỗi khối và thời gian khối trung bình là 10 phút, tương đương với thông lượng dữ liệu chỉ 6KB / s. Các giải pháp lớp 2 tuyên bố là có chủ quyền Bản tổng hợp có thể không thể xuất bản tất cả dữ liệu DA trên chuỗi BTC, do đó họ có thể chọn các phương pháp thay thế, chẳng hạn như xuất bản dữ liệu DA ngoài chuỗi và lưu trữ dữ liệu băm trên chuỗi BTC như một hình thức "cam kết" hoặc tìm cách nén dữ liệu DA cao (ví dụ: sử dụng State diff + ZK Proof như tuyên bố của Chainway). Rõ ràng, chế độ này không phù hợp với định nghĩa của "sovereign Rollup" hoặc một Rollup thích hợp, đại diện cho một biến thể có vấn đề về bảo mật. Chúng tôi dự đoán rằng hầu hết các dự án Lớp 2 mang biểu ngữ "Tổng hợp" cuối cùng sẽ không xuất bản tất cả dữ liệu DA trên chuỗi BTC, vì vậy các giải pháp thực tế của họ có thể sẽ không khớp với tuyên bố "ZK Rollup" hoặc "OP Rollup" được đưa ra trong whitepaper của họ.

Cuối cùng, hãy tóm tắt ngắn gọn các khác biệt giữa Sovereign Rollups và Smart Contract Rollups:

  1. Khả năng nâng cấp:Các phiên bản cập nhật của hợp đồng thông minh Rollups liên quan đến việc cập nhật các hợp đồng thông minh, yêu cầu đội ngũ phát triển sử dụng các hợp đồng có thể nâng cấp. Loại cập nhật hợp đồng thông minh này thường được kiểm soát bởi đội ngũ phát triển Rollup thông qua nhiều chữ ký. Ngược lại, các quy tắc cập nhật cho các Rollups chủ quyền tương tự như các bifurcation mềm và cứng của blockchain truyền thống, nơi các nút có thể chọn cập nhật phiên bản một cách độc lập, và các khách hàng khác nhau có thể chọn xem có chấp nhận việc nâng cấp hay không. Từ góc độ này, Rollups chủ quyền vượt trội so với Rollups hợp đồng thông minh về khả năng nâng cấp.

  2. Cầu:Trong điều kiện lý tưởng, các cầu cho các Rollups hợp đồng thông minh tuân theo sự tin cậy tối thiểu, nhưng khả năng nâng cấp của các hợp đồng có thể ảnh hưởng đến tính bảo mật của chúng. Theo kế hoạch Rollup chủ quyền, các nhà phát triển cần xây dựng các thành phần cầu nối trên chuỗi Layer 1 một cách tự lập, và các cầu được xây dựng có thể tin cậy ít hơn so với các cầu hợp đồng thông minh.

Cấu trúc DA của BTC

Trong đoạn văn trên, chúng tôi đã đề cập rằng để triển khai một Rollup chủ quyền dựa trên BTC, điều quan trọng nằm ở việc sử dụng giao thức Ordinals để làm cho BTC phục vụ như lớp Data Availability (DA). Chainway đã áp dụng giải pháp này.

Chúng ta có thể xem xét một bản ghi dữ liệu DA từ trình tự Chainway, với mã giao dịch là:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, được minh họa như sau:


Kịch bản giao dịch này mượn cách tiếp cận của Giao thức Ordinals sử dụng OP_0 OP_IF để ghi dữ liệu vào việc viết dữ liệu DA (Data Availability) của Rollup lên chuỗi BTC. Điều này liên quan đến việc công bố các thay đổi trạng thái và ZK Proofs, tương đương về mặt bảo mật với việc công bố dữ liệu giao dịch ban đầu nhưng cho phép giảm kích thước dữ liệu đáng kể. Ngoài dữ liệu DA, người sắp xếp cũng ghi một số dữ liệu xác thực vào giao dịch, với điểm quan trọng nhất là người sắp xếp Rollup ký dữ liệu DA bằng khóa riêng để đảm bảo việc nộp hồ sơ đến từ người sắp xếp. Quan trọng nhấn rằng bất kỳ giao dịch nào liên quan đến việc nộp dữ liệu DA đều có 16 số không nhị phân ở cuối băm giao dịch (tức là, hai byte liên tiếp là không). Hạn chế này có thể thấy trong mã:

Trong biểu đồ giao dịch ví dụ đã đề cập trước đó, số ngẫu nhiên "b715" được sử dụng để điều chỉnh giá trị băm của giao dịch sao cho đuôi của nó mang 16 số không cụ thể. Nguyên tắc này tương tự như khai thác Bitcoin, trong đó một số ngẫu nhiên nonce được thêm vào để làm cho các bit N đứng đầu của hàm băm trở thành tất cả các số không, đáp ứng các điều kiện ràng buộc cụ thể. Thiết kế này nhằm mục đích đơn giản hóa khó khăn trong việc lấy dữ liệu DA (Data Availability). Khi bất kỳ nút Layer2 nào muốn truy cập dữ liệu DA, nó chỉ cần quét khối BTC (Bitcoin) cho tất cả các giao dịch được đặt để kết thúc bằng 16 số không, phân biệt hiệu quả các giao dịch được khởi tạo bởi trình phân loại Chainway khi gửi dữ liệu từ các giao dịch khác trên blockchain Bitcoin. Trong văn bản sau, các giao dịch như vậy chứa dữ liệu DA và đáp ứng yêu cầu kết thúc bằng 16 số 0 được gọi là "giao dịch tiêu chuẩn Chainway". Trọng tâm của bài viết này là về cách Chainway đạt được khả năng chống kiểm duyệt. Vì trình phân loại Lớp 2 có thể cố tình từ chối yêu cầu giao dịch từ một người dùng cụ thể, nên phải sử dụng một sơ đồ đặc biệt để cho phép người dùng bắt đầu các giao dịch chống lại kiểm duyệt. Để giải quyết vấn đề này, Chainway cho phép người dùng khởi chạy "Giao dịch bắt buộc". Khi người dùng gửi khai báo giao dịch này trong khối BTC, trình phân loại Chainway phải xử lý yêu cầu giao dịch này trên Lớp 2; Nếu không, nó sẽ không thể tạo ra một khối bình thường hoặc khối được tạo ra sẽ không được nhận ra bởi các máy khách ngoài chuỗi. Cấu trúc tham số của giao dịch bắt buộc như sau:

Giao dịch này sẽ được gửi đến blockchain Bitcoin dưới dạng “Giao dịch Đặc tả Chuỗi,” với mã hash giao dịch kết thúc bằng 16 số không. Người sắp xếp ChainWay, khi tạo các khối L2, phải bao gồm “Giao dịch Đặc tả Tầng 2” đã được tiết lộ trên blockchain BTC nhưng chưa được ghi vào sổ cái L2, và tổng hợp chúng thành Mạng Merkle, viết gốc Merkle của nó vào tiêu đề khối L2. Khi một người dùng khởi tạo một giao dịch cưỡng chế trực tiếp trên blockchain BTC, người sắp xếp phải xử lý nó; nếu không, nó không thể tạo ra khối hợp lệ kế tiếp. Khách hàng Chainway ngoài chuỗi BTC có thể xác minh chứng minh ZK trước để xác định tính hợp lệ của khối L2 được gửi bởi người sắp xếp, kiểm tra gốc Merkle của tiêu đề khối L2, và xem xét liệu người sắp xếp đã bao gồm yêu cầu giao dịch cưỡng chế một cách trung thực. Quy trình làm việc có thể tham khảo biểu đồ luồng dưới đây. Lưu ý rằng, do hạn chế không gian, biểu đồ dưới đây thiếu một sự xét đoán điều kiện trong verify_relevant_tx_list:

Tóm lại, máy khách / nút Chainway đồng bộ hóa với các khối mạng chính BTC và quét "dữ liệu DA" được xuất bản bởi trình phân loại Chainway từ chúng. Nó xác minh rằng những dữ liệu này được xuất bản bởi trình phân loại được chỉ định và thực sự chứa tất cả các "giao dịch tiêu chuẩn Chainway" được gửi đến chuỗi BTC. Rõ ràng là miễn là người dùng có thể xây dựng một giao dịch đáp ứng các tiêu chí được chỉ định là "giao dịch tiêu chuẩn" và gửi nó đến chuỗi BTC, giao dịch này cuối cùng sẽ được đưa vào sổ cái L2 cục bộ của khách hàng Chainway. Nếu không, khối L2 được phát hành bởi trình sắp xếp Chainway sẽ bị máy khách từ chối. Nếu kết hợp với truyền tin nhắn cảnh báo / đồng thuận ngoài chuỗi đáng tin cậy, kế hoạch giao dịch chống kiểm duyệt của Chainway tiếp cận phương pháp chống kiểm duyệt lý tưởng của Rollups có chủ quyền. Ví dụ: một số giải pháp Rollup có chủ quyền đã tuyên bố rõ ràng rằng trong trường hợp chặn không hợp lệ, các thông báo cảnh báo Cảnh báo sẽ được phát giữa các máy khách ngoài chuỗi để tăng cường bảo mật, đặc biệt là cho phép các máy khách nhẹ không thể đồng bộ hóa dữ liệu DA hoàn chỉnh biết về sự bất thường của mạng. Nếu một khối không trung thực bao gồm "các giao dịch bắt buộc", rõ ràng nó sẽ kích hoạt một chương trình phát sóng cảnh báo ngoài chuỗi. Tuy nhiên, Chainway vẫn chưa triển khai khía cạnh này (ít nhất là các tài liệu và kho lưu trữ mã được công bố hiện tại cho thấy họ chưa thực hiện việc triển khai kỹ thuật của phần này).

Tài liệu tham khảo: Các nhà nghiên cứu Celestia phân tích 6 loại biến thể Rollup: Sequencer = Aggregator + Header Generator. Ngay cả với sự đồng thuận đạt được giữa các khách hàng / nút ngoài chuỗi, hiệu quả chống kiểm duyệt của "giao dịch bắt buộc" của Chainway không mạnh mẽ như các bản tổng hợp hợp đồng thông minh như Arbitrum, bởi vì Arbitrum One cuối cùng sẽ đảm bảo "giao dịch bắt buộc" được đưa vào sổ cái Layer2 thông qua các hợp đồng trên Layer1, kế thừa đầy đủ các đặc tính chống kiểm duyệt của Layer1. Sovereign Rollups rõ ràng không thể phù hợp với các bản tổng hợp hợp đồng thông minh ở khía cạnh này, vì hiệu quả chống kiểm duyệt của chúng cuối cùng phụ thuộc vào các thành phần ngoài chuỗi. Điều này cũng xác định rằng cách tiếp cận của các chương trình "Sovereign Rollups" và "client verification" về cơ bản không thể kế thừa đầy đủ các thuộc tính chống kiểm duyệt của Layer1, như Arbitrum One, Loopring, dydx và Degate, bởi vì liệu các giao dịch bắt buộc có thể được đưa vào sổ cái Layer2 hay không phụ thuộc vào quyết định của các thực thể ngoài chuỗi Layer2, không liên quan đến chính Layer1. Rõ ràng, cách tiếp cận của Chainway, chỉ dựa vào quyết định của các khách hàng ngoài chuỗi, chỉ kế thừa độ tin cậy DA của Layer1, chứ không phải các đặc tính chống kiểm duyệt đầy đủ của nó. Tương tự như các bằng chứng ZK đệ quy của MINA.

Trong phần này, chúng tôi sẽ giới thiệu thêm các thành phần khác của Chainway, ngoài việc sử dụng BTC như là lớp DA, cũng thực hiện các chứng minh ZK đệ quy tương tự như MINA. Cấu trúc tổng thể của nó được minh họa trong sơ đồ sau:


Trình phân loại trong mạng Chainway, sau khi xử lý các giao dịch của người dùng, tạo ra bằng chứng ZK (Zero-Knowledge) cuối cùng cùng với các chi tiết về thay đổi trạng thái (trạng thái khác biệt) cho các tài khoản khác nhau và xuất bản chúng trên blockchain Bitcoin (BTC). Các nút đầy đủ sẽ đồng bộ hóa tất cả dữ liệu lịch sử của Chainway được công bố trên blockchain BTC. Mỗi bằng chứng ZK không chỉ phải chứng minh quá trình chuyển đổi trạng thái của khối hiện tại mà còn đảm bảo tính hợp lệ của bằng chứng ZK của khối trước đó. Dựa trên sơ đồ này, chúng ta có thể thấy rằng mỗi khi một bằng chứng mới được tạo ra, về cơ bản nó xác nhận chứng minh trước đó theo cách đệ quy và bằng chứng ZK mới nhất có thể đảm bảo tính hợp lệ của tất cả các bằng chứng ZK bắt đầu từ khối gốc. Thiết kế này tương tự như của MINA. Khi một "light client" chỉ đồng bộ hóa các tiêu đề khối, còn được gọi là light node, tham gia mạng, nó chỉ cần xác minh tính hợp lệ của ZK Proof mới nhất được tiết lộ trên blockchain BTC để xác nhận rằng toàn bộ dữ liệu lịch sử của chuỗi và tất cả các chuyển đổi trạng thái là hợp lệ. Nếu trình phân loại hành động độc hại, cố ý từ chối chấp nhận các giao dịch bắt buộc hoặc không sử dụng bằng chứng ZK trước đó để chứng minh đệ quy, thì khách hàng không thể chấp nhận bằng chứng ZK mới được tạo (ngay cả khi được tạo, nó không được công nhận), như thể hiện trong sơ đồ dưới đây:

Tóm tắt

Như được tóm tắt ở đầu bài viết này, Chainway về cơ bản là một lược đồ Rollup/client chủ quyền sử dụng BTC như một lớp Data Availability (DA). Để tăng cường khả năng chống kiểm duyệt của Rollup, Chainway giới thiệu khái niệm giao dịch bắt buộc. Trong khi đó, Chainway sử dụng công nghệ chứng minh ZK đệ quy, cho phép các nút mới tin tưởng vào kết quả của sequencer hơn và xác minh tính chính xác của dữ liệu lịch sử của toàn bộ chuỗi bất kỳ lúc nào. Vấn đề hiện tại của Chainway nằm ở cơ chế tin cậy của cầu nối qua chuỗi của nó. Bởi vì nó áp dụng phương pháp Rollup chủ quyền mà không chỉ rõ cách nó dự định giải quyết các chi tiết kỹ thuật trong giải pháp cầu nối qua chuỗi của mình, việc đánh giá tính an toàn cuối cùng của nó là khó khăn.

Hôm nay, bằng cách đào sâu vào giải pháp kỹ thuật của Chainway, chúng tôi phát hiện rằng loại công nghệ được quảng bá bởi cộng đồng dự án không phải là một Rollup trong ý nghĩa chủ yếu. Xét đến sự hiện diện của hàng chục dự án Bitcoin Layer2 (có thể lên tới hàng trăm trong nửa năm), để giảm chi phí nhận thức về thuật ngữ kỹ thuật, chúng tôi sẽ tiếp tục tiến hành nghiên cứu sâu rộng về phân loại các giải pháp Layer2 và tiêu chuẩn về bảo mật, đầy đủ chức năng và đánh giá. Hãy theo dõi!

Disclaimer:

  1. Bài viết này được in lại từ [Web3 của Gate]. Tất cả bản quyền thuộc về tác giả gốc [Shew & Faust, web3 của các chuyên gia]. Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ với Gate Học và họ sẽ xử lý kịp thời.
  2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không đưa ra bất kỳ lời khuyên đầu tư nào.
  3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu rõ, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.
Розпочати зараз
Зареєструйтеся та отримайте ваучер на
$100
!