Giải mã công nghệ Chainway: Các dự án Bitcoin Layer2 làm thế nào để lợi dụng khái niệm (1)
Tuyển chọn TechFlowTuyển chọn TechFlow
Giải mã công nghệ Chainway: Các dự án Bitcoin Layer2 làm thế nào để lợi dụng khái niệm (1)
Chainway về cơ bản là một giải pháp rollup chủ quyền/sổ cái xác minh khách hàng sử dụng BTC làm lớp DA.
Chuyên sâu báo cáo Web3Tác giả: Shew & Faust, Geeker web3
Hiện tại, lĩnh vực Bitcoin Layer2 có thể nói là muôn hình vạn trạng, khi hàng loạt giải pháp công nghệ khác nhau đổ dồn về "lò luyện lớn" hệ sinh thái BTC. Do tốc độ đổi mới trong lĩnh vực blockchain rất nhanh, các thuật ngữ chuyên môn hay tiêu chuẩn đều liên tục thay đổi trong quá trình nghiên cứu sáng tạo và triển khai thực tế. Trong bối cảnh này, nhiều dự án sử dụng chiêu thức "tạo khái niệm"/"nhờn khái niệm" để tạo sự khác biệt và thu hút sự chú ý, điều này đã trở thành quy tắc ngầm trong ngành.
Ví dụ, nhiều dự án blockchain mô-đun vốn hoạt động chủ yếu trên hệ sinh thái Ethereum/Celestia cũng nhân cơ hội thuận lợi, nhảy lên chuyến tàu nhanh mang tên “Bitcoin Layer2”, tự phong mình là “Rollup”, dù giải pháp kỹ thuật của họ thường không đáp ứng tiêu chuẩn Rollup.
Tuy nhiên, từ ngữ như “Rollup” lại có mức độ công nhận cao, việc lấy danh nghĩa “Rollup” thuận tiện hơn cho truyền thông. Nhiều đội ngũ dự án hoặc là cố tình “nhờn” (tự xưng là Rollup), hoặc sao chép khái niệm Rollup phổ biến (thêm một tính từ mập mờ như Rollup chủ quyền).
Nhưng nếu gỡ bỏ lớp áo “XX Rollup” ra, rất nhiều dự án thực chất vận hành theo nguyên lý đơn thuần là “xác minh ở phía khách hàng” hoặc “sidechain”, chỉ đang mượn khẩu hiệu “XX Rollup” để phục vụ mục đích quảng bá cho bản thân. Cách tiếp cận truyền thông này tuy khá phổ biến nhưng thường gây hiểu lầm, đối với đại chúng luôn theo đuổi sự thật thì tác hại mang lại nhiều hơn lợi ích.
(Tổng kết của Bộ trưởng tuyên truyền phát xít Goebbels về “tuyên truyền kiểu dối trá”, phương pháp này xuất hiện phổ biến ở nhiều đội ngũ dự án)
Vậy làm thế nào để phân biệt những hành vi “nhờn概念 Rollup” này?
Có lẽ, cần xuất phát từ nguyên lý đầu tiên, dựa trên các tiêu chuẩn được phương Tây và cộng đồng công nghiệp rộng rãi công nhận để định nghĩa loại hình giải pháp, mức độ an toàn, và tính đầy đủ chức năng của các dự án Layer2 khác nhau, mới có thể mở ra đôi “mắt Rinnegan vạn hoa” giúp ta nhìn rõ thực chất giữa làn sương mù. Hay nói cách khác, việc sử dụng giải pháp gì không quan trọng bằng cốt lõi thiết kế cơ chế của dự án có đảm bảo mạng Layer2 an toàn, đáng tin cậy hay không, có thực sự trao quyền cho mainnet BTC hay không.
Dưới đây, chúng tôi sẽ dùng Chainway – một dự án Bitcoin Layer2 do người nước ngoài phát triển – làm ví dụ, phân tích bản chất “xác minh ở phía khách hàng” ẩn sau khẩu hiệu “Rollup” mà một số dự án đưa ra. Chúng ta có thể thấy rõ hơn sự khác biệt rõ rệt giữa “Rollup chủ quyền”, “xác minh ở phía khách hàng” với các giải pháp Rollup dựa trên hợp đồng thông minh như ZKRollup hay OPRollup theo nghĩa thông thường của ngành công nghiệp.
Tất nhiên, điều này không có nghĩa rằng Rollup chủ quyền hay xác minh ở phía khách hàng kém an toàn, đáng tin cậy hơn ZK Rollup – mọi thứ đều phụ thuộc vào chi tiết triển khai cụ thể. Dù Chainway là một Layer2 điển hình dựa trên xác minh phía khách hàng, nhưng nó đề xuất phương án giao dịch chống kiểm duyệt “kích hoạt trên BTC + xác minh bên ngoài chuỗi”, đồng thời áp dụng chứng minh ZK đệ quy tương tự như chuỗi MINA, dẫn đầu so với đa số các dự án Bitcoin Layer2 khác.
Chúng tôi cho rằng, việc khảo sát kỹ thuật đối với Chainway là khá giá trị, có ý nghĩa tham khảo quan trọng đối với đông đảo những người theo dõi Bitcoin Layer2.
(Hình ảnh quảng bá của Chainway, tự quảng cáo là ZK Rollup, nhưng giải pháp thực tế là xác minh ở phía khách hàng; hiện tại chưa đạt được sự đồng thuận giữa các client bên ngoài chuỗi hoặc trao đổi thông tin đáng tin cậy)
Nội dung chính: Chainway là một dự án Bitcoin Layer2 khá nổi tiếng trong cộng đồng phương Tây. Khi quảng bá, nhiều KOL trực tiếp gọi nó là “ZK Rollup”, còn trong tài liệu kỹ thuật, Chainway tự định vị là “Rollup chủ quyền”. Gần đây, Chainway còn công bố một dự án mới Citrea, tự xưng là ZK Rollup dựa trên BitVM. Vì Citrea vẫn chưa giải thích rõ cách thức triển khai chứng minh ZK dựa trên BitVM, bài viết này sẽ tập trung vào phân tích kỹ thuật dựa trên giải pháp hiện tại của Chainway.
Chúng ta có thể tóm gọn giải pháp kỹ thuật đã công bố của Chainway trong một câu: Công bố dữ liệu DA thông qua giao thức Ordinals, sử dụng BTC làm tầng DA, đăng tải chi tiết thay đổi trạng thái (State diff) + chứng minh tính đúng đắn của thay đổi trạng thái (ZK Proof) lên Layer1, hiệu quả tương đương với việc công bố toàn bộ dữ liệu giao dịch có thể xác minh.
(State diff là lượng thay đổi trạng thái tài khoản)
Tuy nhiên, vì Layer1 không trực tiếp xác minh ZK Proof, công việc xác minh do các client/nút độc lập bên ngoài chuỗi thực hiện, và kho mã nguồn hiện tại của Chainway chưa triển khai cơ chế đồng thuận giữa các client độc lập bên ngoài chuỗi, đội ngũ chính thức cũng chưa tuyên bố trên mạng xã hội rằng đã giải quyết vấn đề này. Do đó, giải pháp kỹ thuật công bố hiện tại của Chainway về bản chất thuộc loại “xác minh ở phía khách hàng”, thậm chí còn giống một giao thức chỉ mục inscription hỗ trợ cầu nối tài sản hơn.
Phần sau sẽ giới thiệu chi tiết triển khai kỹ thuật của Chainway và phân tích mô hình bảo mật của nó.
Rollup chủ quyền là gì: Phát hành dữ liệu trên tầng DA + Xác minh bên ngoài chuỗi
Trong tài liệu kỹ thuật của Chainway, khái niệm Rollup chủ quyền (sovereign rollup) của Celestia được sử dụng. Tuy nhiên, Rollup chủ quyền thực tế hoàn toàn khác biệt so với khái niệm Rollup phổ biến trong cộng đồng Ethereum và ngành công nghiệp (Rollup hợp đồng thông minh). Vậy cấu trúc cụ thể của Rollup chủ quyền là gì?
Thực tế Rollup chủ quyền dựa trên Bitcoin phần nào giống với —— “nhóm client bên ngoài chuỗi / sidechain công bố dữ liệu DA trên chuỗi BTC”, đặc điểm lớn nhất là không cần hợp đồng thông minh trên Layer1 xác minh chuyển đổi trạng thái / hành vi cross-chain của Layer2, về bản chất chỉ dùng BTC làm tầng DA, mô hình bảo mật gần giống với “xác minh ở phía khách hàng” (client side validation).
Tất nhiên, một số giải pháp Rollup chủ quyền có độ an toàn cao hơn sẽ dựa vào tầng thanh toán thứ ba bên ngoài chuỗi BTC (tương tự sidechain) để hoàn tất xác minh chuyển đổi trạng thái, và giữa các client/đầy đủ nút độc lập tồn tại một tầng đồng thuận hoặc truyền tin nhắn đáng tin cậy, nhằm đạt được “sự nhất trí” về những hành vi tranh cãi nhất định. Nhưng một số dự án Rollup chủ quyền lại là dạng “xác minh ở phía khách hàng” trần trụi, không có truyền tin nhắn đáng tin cậy giữa các client/điểm độc lập.
Để hiểu rõ hơn khái niệm đặc biệt “Rollup chủ quyền”, chúng ta có thể so sánh Rollup chủ quyền với Rollup hợp đồng thông minh tương ứng. Layer2 trên Ethereum về cơ bản đều là Rollup hợp đồng thông minh, như Arbitrum và StarkNet. Cấu trúc Rollup hợp đồng thông minh có thể tham khảo hình dưới đây:
Trong hình trên, chúng ta có thể thấy một vài thuật ngữ trong câu chuyện blockchain mô-đun, giải thích như sau:
Tầng thực thi (Execution): Thực thi giao dịch người dùng, cập nhật trạng thái blockchain, gửi dữ liệu đến tầng DA và tầng thanh toán
Tầng thanh toán (Settlement): Xác minh chuyển đổi trạng thái của tầng thực thi, giải quyết tranh chấp (ví dụ như bằng chứng gian lận), và cung cấp module cầu nối xử lý tài sản L1-L2
Tầng DA: Một bảng thông báo lớn, nhận dữ liệu chuyển đổi trạng thái từ tầng thực thi, cung cấp dữ liệu này một cách phi tin nhiệm cho bất kỳ ai
Tầng đồng thuận (Consensus): Đảm bảo tính cuối cùng của việc sắp xếp giao dịch, chức năng gần giống với tầng DA (phân tầng blockchain mô-đun của cộng đồng Ethereum không bao gồm tầng đồng thuận)
Từ kiến trúc Rollup hợp đồng thông minh, ta thấy ngoài tầng thực thi, ba tầng còn lại đều do Ethereum đảm nhận. Hình dưới đây minh họa chi tiết hơn vai trò của Ethereum trong Rollup hợp đồng thông minh.
Rollup contract trên Ethereum nhận bằng chứng hiệu lực (validity proof) hoặc bằng chứng gian lận (fraud proof) để xác minh tính hiệu lực của việc chuyển đổi trạng thái Layer2. Đáng chú ý, Rollup smart contract ở đây thực chất là thực thể tầng thanh toán trong blockchain mô-đun. Hợp đồng thanh toán thường bao gồm module cầu nối, xử lý tài sản được cầu nối từ Ethereum sang Layer2.
Đối với DA, hợp đồng Rollup có thể yêu cầu bắt buộc sequencer phải đưa dữ liệu giao dịch mới nhất / chi tiết thay đổi trạng thái lên chuỗi, nếu không đưa DA lên chuỗi thì không thể cập nhật trạng thái L2 được ghi trong hợp đồng Rollup.
(ZK Rollup hoặc OP Rollup có thể yêu cầu bắt buộc dữ liệu DA phải lên chuỗi, nếu không sẽ không thể cập nhật trạng thái ghi trong tầng thanh toán)
Tài liệu tham khảo:Phân tích mô hình an toàn và chỉ số rủi ro Layer2 của Bitcoin/Ethereum bằng lý thuyết thùng gỗ
Ta có thể thấy, Rollup hợp đồng thông minh cực kỳ phụ thuộc vào hợp đồng thông minh trên Layer1, đối với BTC - Layer1 khó hỗ trợ logic nghiệp vụ phức tạp - thì hầu như không thể xây dựng Layer2 "đồng bộ" với Rollup Ethereum.
Trong khi đó, giải pháp Rollup chủ quyền hoàn toàn không cần hợp đồng trên Layer1 xác minh chuyển đổi trạng thái / xử lý cầu nối. Kiến trúc của nó như hình dưới:
Ta thấy rằng, trong Rollup chủ quyền, nhóm nút bên ngoài tầng DA đóng vai trò thực thi giao dịch và xử lý thanh toán, có độ tự do cao hơn. Quy trình hoạt động cụ thể như sau:
Các nút thực thi của Rollup chủ quyền gửi dữ liệu giao dịch / chi tiết thay đổi trạng thái đến tầng DA, trong khi tầng thanh toán/client tìm cách lấy dữ liệu và thực hiện xác minh. Lưu ý rằng, vì module thanh toán không nằm trên Layer1 nên về lý thuyết Rollup chủ quyền không thể đạt được cầu nối có mức độ an toàn tương đương Layer1, thường phải dựa vào cầu nối công chứng hoặc giải pháp cầu nối bên thứ ba.
Hiện tại, việc triển khai Rollup chủ quyền / giải pháp xác minh ở phía khách hàng tương đối dễ, chỉ cần thực hiện phát hành dữ liệu trên chuỗi BTC, dùng dạng giao thức tương tự Ordinals. Phần xác minh và đồng thuận bên ngoài chuỗi có không gian tự do lớn, thậm chí nhiều sidechain chỉ cần phát hành dữ liệu DA lên BTC, về cơ bản đã trở thành “Rollup chủ quyền dựa trên BTC”, mặc dù mức độ an toàn cụ thể còn đáng nghi ngờ.
Tuy nhiên vấn đề nằm ở chỗ, khả năng xử lý dữ liệu của Bitcoin cực kỳ thấp, mỗi khối tối đa 4MB, thời gian trung bình tạo khối là 10 phút, tính ra băng thông dữ liệu chỉ khoảng 6KB/s. Các giải pháp Layer2 tự xưng là Rollup chủ quyền hiện nay có thể không thể công bố toàn bộ dữ liệu DA lên chuỗi BTC, do đó phải dùng các phương án dung hòa khác: ví dụ như công bố dữ liệu DA bên ngoài chuỗi, lưu datahash lên chuỗi BTC như một “cam kết”. Hoặc tìm ra phương pháp nén dữ liệu DA ở mức độ cao (ví dụ như State diff+ZK Proof mà Chainway tự xưng).
Rõ ràng mô hình này không phù hợp định nghĩa “Rollup chủ quyền” hoặc Rollup nghiêm chỉnh, chỉ là dạng biến thể, mức độ an toàn còn phải bàn cãi. Chúng tôi dự đoán, trong tương lai đa số dự án Layer2 mang danh “Rollup” cuối cùng sẽ không công bố đầy đủ dữ liệu DA lên chuỗi BTC, do đó giải pháp thực tiễn của họ gần như chắc chắn không phù hợp với khẩu hiệu “ZK Rollup”, “OP Rollup” trên giấy trắng.
Cuối cùng, hãy tóm tắt ngắn gọn sự khác biệt giữa Rollup chủ quyền và Rollup hợp đồng thông minh:
Thứ nhất, khả năng nâng cấp. Việc cập nhật Rollup hợp đồng thông minh liên quan đến việc cập nhật hợp đồng thông minh, đòi hỏi đội phát triển sử dụng hợp đồng có thể nâng cấp. Quyền nâng cấp hợp đồng thông minh này thường do đội phát triển Rollup kiểm soát bằng multi-sig. Trong khi đó, quy tắc nâng cấp của Rollup chủ quyền tương tự fork mềm/cứng của blockchain thông thường, các nút có thể tự chọn phiên bản cập nhật, các client khác nhau có thể chọn chấp nhận nâng cấp hay không. Xét theo điểm này, Rollup chủ quyền vượt trội hơn Rollup hợp đồng thông minh.
Thứ hai, cầu nối. Cầu nối của Rollup hợp đồng thông minh trong điều kiện lý tưởng là tối thiểu hóa niềm tin, nhưng khả năng nâng cấp hợp đồng ảnh hưởng đến độ an toàn. Trong khi đó, theo giải pháp Rollup chủ quyền, nhà phát triển phải tự xây dựng thành phần cầu nối bên ngoài chuỗi Layer1, cầu nối tạo ra gần như chắc chắn không đạt mức độ phi tin nhiệm như cầu nối hợp đồng thông minh.
Xây dựng tầng DA trên BTC
Ở phần trước, chúng tôi đã đề cập rằng, để thực hiện Rollup chủ quyền dựa trên BTC, then chốt là sử dụng giao thức Ordinals để biến BTC thành tầng DA. Chainway sử dụng đúng giải pháp này.
Chúng ta có thể quan sát một lần nộp dữ liệu DA từ sequencer của Chainway, hash giao dịch là:
24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, sơ đồ minh họa như sau:
Mã script của giao dịch này mượn giải pháp ghi dữ liệu OP_0 OP_IF từ Ordinals Protocol để ghi dữ liệu DA của Rollup vào chuỗi BTC (công bố thay đổi trạng thái + ZK Proof, về mặt bảo mật tương đương công bố dữ liệu giao dịch gốc, nhưng kích thước dữ liệu có thể được nén mạnh mẽ).
Tất nhiên, ngoài dữ liệu DA, sequencer cũng ghi thêm một số dữ liệu ủy quyền trong giao dịch, quan trọng nhất là sequencer Rollup ký dữ liệu DA bằng khóa riêng của mình, đảm bảo dữ liệu DA được nộp bởi sequencer.
Ở đây chúng ta cũng cần lưu ý rằng, mọi giao dịch liên quan đến việc nộp dữ liệu DA đều có 16 bit 0 ở đuôi hash giao dịch (tức là 2 byte liên tiếp đều bằng 0). Trong mã nguồn, ta có thể thấy giới hạn này:
Số ngẫu nhiên b715 trong hình minh họa giao dịch trước nhằm điều chỉnh giá trị hash của giao dịch này sao cho đuôi nó mang 16 bit 0 nhất định, nguyên lý tương tự việc thêm nonce trong khai thác Bitcoin để hash có N bit đầu bằng 0, thỏa mãn điều kiện giới hạn nhất định.
Thiết kế này nhằm đơn giản hóa việc thu thập dữ liệu DA, khi bất kỳ nút Layer2 nào muốn lấy dữ liệu DA, chỉ cần quét các giao dịch trong khối BTC có đuôi đặt 16 bit 0, tương đương tách biệt rõ ràng giao dịch mà sequencer Chainway nộp dữ liệu với các giao dịch khác trên chuỗi Bitcoin. Sau này, ta gọi các giao dịch chứa dữ liệu DA và thỏa mãn điều kiện đuôi 16 bit 0 là “giao dịch chuẩn Chainway”.
Vậy đến trọng tâm được nêu trong tiêu đề bài viết: Chainway thực hiện chống kiểm duyệt như thế nào? Vì sequencer Layer2 có thể cố ý từ chối yêu cầu giao dịch của người dùng, ta cần một giải pháp đặc biệt để người dùng khởi tạo giao dịch chống kiểm duyệt.
Đối với vấn đề này, Chainway cho phép người dùng khởi tạo “giao dịch bắt buộc” (Forced Transaction). Khi người dùng nộp tuyên bố giao dịch này vào khối BTC, sequencer Chainway phải xử lý yêu cầu giao dịch này trên Layer2, nếu không sẽ không thể tạo khối bình thường, hoặc khối tạo ra sẽ không được client bên ngoài chuỗi công nhận.
Cấu trúc tham số giao dịch bắt buộc như sau:
Giao dịch này sẽ được nộp lên chuỗi Bitcoin như một “giao dịch chuẩn Chainway”, đuôi hash có 16 bit 0. Khi sequencer Chainway tạo khối L2, phải bao gồm các “giao dịch chuẩn Layer2” đã tiết lộ trên chuỗi BTC nhưng chưa được ghi vào sổ cái L2, tổng hợp thành cây Merkle, ghi root Merkle vào tiêu đề khối L2.
Khi người dùng trực tiếp khởi tạo giao dịch bắt buộc trên chuỗi BTC, sequencer phải xử lý, nếu không sẽ không thể tạo khối hợp lệ tiếp theo. Client Chainway bên ngoài chuỗi BTC có thể trước tiên kiểm tra ZK proof, xác định tính hợp lệ của khối L2 do sequencer nộp, kiểm tra root Merkle trong tiêu đề khối L2, đánh giá sequencer có trung thực bao gồm yêu cầu giao dịch bắt buộc hay không.
Quy trình làm việc có thể tham khảo sơ đồ sau. Lưu ý, do giới hạn độ dài, sơ đồ dưới thiếu một điều kiện kiểm tra ở verify_relevant_tx_list:
Tóm lại, client/nút Chainway sẽ đồng bộ khối chính mạng BTC, từ đó quét ra “dữ liệu DA” do sequencer Chainway công bố, xác nhận dữ liệu này do sequencer chỉ định phát hành và thực sự bao gồm toàn bộ “giao dịch chuẩn Chainway” đã nộp lên chuỗi BTC.
Không khó để thấy rằng, miễn là người dùng có thể tạo một “giao dịch chuẩn” đáp ứng điều kiện giới hạn và nộp lê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 client Chainway, nếu không khối L2 do sequencer Chainway phát hành sẽ bị client từ chối.
Nếu kết hợp với đồng thuận bên ngoài chuỗi / truyền tin nhắn cảnh báo đáng tin cậy, giải pháp giao dịch chống kiểm duyệt của Chainway sẽ tiến gần đến phương pháp lý tưởng của Rollup chủ quyền. Ví dụ, một số giải pháp Rollup chủ quyền từng tuyên bố rõ ràng rằng, khi gặp khối vô hiệu, sẽ phát tán thông tin cảnh báo Alert giữa các client bên ngoài chuỗi để tăng cường bảo mật, đặc biệt giúp các client nhẹ không thể đồng bộ toàn bộ dữ liệu DA biết được trạng thái mạng bất thường.
Nếu một khối không trung thực bao gồm “giao dịch bắt buộc”, rõ ràng sẽ kích hoạt phát tán cảnh báo bên ngoài chuỗi, nhưng hiện tại Chainway vẫn chưa triển khai phần này (ít nhất theo tài liệu và kho mã nguồn công bố hiện nay, cho thấy họ chưa làm phần triển khai kỹ thuật này).
Tài liệu tham khảo: Nhà nghiên cứu Celestia phân tích 6 biến thể Rollup: Sequencer = Aggregator + Người tạo Header
Dù có triển khai đồng thuận giữa client/nút bên ngoài chuỗi, hiệu quả chống kiểm duyệt của “giao dịch bắt buộc” Chainway vẫn không bằng Rollup hợp đồng thông minh như Arbitrum, 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 hợp đồng trên Layer1, thừa hưởng đầy đủ tính chống kiểm duyệt của Layer1. Rollup chủ quyền rõ ràng không thể sánh bằng Rollup hợp đồng thông minh ở điểm này, tính chống kiểm duyệt cuối cùng vẫn phụ thuộc vào phần bên ngoài chuỗi.
Điều này quyết định rằng, tư duy giải pháp “Rollup chủ quyền” và “xác minh ở phía khách hàng” về cơ bản không thể thừa hưởng đầy đủ tính chống kiểm duyệt của Layer1 như Arbitrum One, Loopring, dydx hay Degate, vì việc giao dịch bắt buộc có đượ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ể bên ngoài chuỗi Layer2, không liên quan gì đến bản thân Layer1.
Rõ ràng, Chainway với giải pháp đơn thuần dựa vào client bên ngoài chuỗi tự quyết định, chỉ thừa hưởng độ tin cậy DA của Layer1, không thừa hưởng đầy đủ tính chống kiểm duyệt của nó.
Chứng minh ZK đệ quy tương tự MINA
Trong phần này, chúng tôi sẽ giới thiệu sâu hơn các thành phần khác của Chainway. Ngoài việc sử dụng BTC làm tầng DA, nó còn triển khai chứng minh ZK đệ quy tương tự MINA. Cấu trúc tổng thể như hình dưới:
Sau khi sequencer mạng Chainway xử lý xong giao dịch người dùng, tạo ra chứng minh ZK cuối cùng, kèm theo chi tiết thay đổi trạng thái tài khoản (state diff), công bố lên chuỗi BTC. Các nút đầy đủ sẽ đồng bộ toàn bộ dữ liệu lịch sử Chainway trên BTC. Mỗi chứng minh ZK không chỉ chứng minh quá trình chuyển đổi trạng thái khối hiện tại mà còn phải đảm bảo chứng minh ZK khối trước đó hợp lệ.
Dựa trên giải pháp trên, ta thấy mỗi lần tạo chứng minh mới thực chất xác nhận chứng minh trước, đệ quy liên tiếp, chứng minh ZK mới nhất có thể đảm bảo tất cả chứng minh ZK từ khối genesis đều hợp lệ. Thiết kế này tương tự MINA.
Khi một “client nhẹ” chỉ đồng bộ tiêu đề khối, tức là nút nhẹ tham gia mạng, chỉ cần xác minh chứng minh ZK mới nhất công bố trên BTC là hợp lệ, có thể xác nhận toàn bộ dữ liệu lịch sử chuỗi, mọi chuyển đổi trạng thái đều hợp lệ.
Nếu sequencer gian ác, cố ý không chấp nhận giao dịch bắt buộc hoặc không dùng chứng minh ZK lần trước để thực hiện chứng minh đệ quy, thì chứng minh ZK mới tạo ra sẽ không được client chấp nhận (tạo ra cũng không được công nhận), như hình dưới:
Tổng kết
Như đã tóm tắt ở đầu bài viết, Chainway về bản chất là một giải pháp Rollup chủ quyền/xác minh ở phía khách hàng sử dụng BTC làm tầng DA. Để nâng cao tính chống kiểm duyệt của Rollup, Chainway đưa ra khái niệm giao dịch bắt buộc. Mặt khác, Chainway sử dụng công nghệ chứng minh ZK đệ quy, giúp các nút mới tham gia tin tưởng hơn vào kết quả đầu ra của sequencer,随时 xác nhận dữ liệu lịch sử toàn chuỗi chính xác.
Vấn đề hiện tại của Chainway nằm ở phần cầu nối xuyên chuỗi nên làm sao để phi tin nhiệm, do sử dụng giải pháp Rollup chủ quyền, chưa nói rõ chi tiết kỹ thuật về giải pháp cầu nối, nên khó đánh giá mức độ an toàn cuối cùng ra sao.
Hôm nay, chúng tôi thông qua phân tích sâu giải pháp kỹ thuật Chainway, phát hiện loại hình công nghệ mà cộng đồng dự án tuyên truyền không phải Rollup theo nghĩa thông thường. Xét thấy hiện tại đã có hàng chục dự án Bitcoin Layer2 (nửa năm nữa có thể lên tới hàng trăm), để giảm chi phí nhận diện thuật ngữ kỹ thuật cho mọi người, chúng tôi sẽ tiếp tục nghiên cứu sâu về phân loại giải pháp Layer2, tiêu chuẩn an toàn và tiêu chuẩn đánh giá tính đầy đủ chức năng, kính mong chờ đón!
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@godrealmx
