Giới thiệu về khối lập phương

Tác giả: Buark

Nguồn: https://medium.com/cube-bitcoin/introducing-cube-8b3702e470a5

" Cube " là một máy ảo được thiết kế đặc biệt để cho phép thực thi hợp đồng thông minh không cần tin tưởng theo cách thức vốn có của Bitcoin. Nó cung cấp một hoàn cảnh thực thi không cần tin tưởng với khả năng thoát lệnh một chiều, đảm bảo người dùng giữ toàn quyền kiểm soát tiền của họ. Bằng cách kết hợp BitVM với "cây thời gian chờ" và sử dụng blockchain Bitcoin làm lớp "khả năng truy cập dữ liệu(DA)", Cube trực tiếp nhúng BTC vào một máy ảo với "trạng thái toàn cục". Phương pháp này kết hợp thiết kế cơ bản của Bitcoin với mô hình thực thi hợp đồng thông minh hoàn chỉnh theo lý thuyết Turing mà không gây ra rủi ro đối tác, do đó cung cấp một khuôn khổ hoàn toàn mới để mở rộng chức năng của Bitcoin.

Chén Thánh

Bitcoin là loại tiền điện tử an toàn nhất và đã được kiểm chứng qua thời gian, nhưng những hạn chế về lập trình và mở rộng đã hạn chế khả năng hỗ trợ các giao dịch tài chính phức tạp vượt ra ngoài các khoản thanh toán ngang hàng. Đây không phải là lỗi. Chúng là những hạn chế được thiết kế có chủ đích để bảo vệ các đặc tính tạo nên giá trị Bitcoin—khả năng chống kiểm duyệt, tự quản lý và khả năng phục hồi. Tuy nhiên, kết quả là Bitcoin không thể hỗ trợ một cách tự nhiên khả năng lập trình, thông lượng và độ phức tạp tài chính cần thiết cho một hoàn cảnh tiền tệ toàn cầu. Hợp đồng thông minh, tài chính phi tập trung và quyết toán tần suất cao đều yêu cầu một hoàn cảnh thực thi mà Bitcoin chưa bao giờ được thiết kế để cung cấp ở lớp cơ bản của nó.

Giải pháp không phải là thay đổi Bitcoin, mà là xây dựng dựa trên nó. Một mạng lưới Layer 2 có ý nghĩa phải mở rộng khả năng của Bitcoin mà không làm mất đi các đặc tính cốt lõi của nó. Nó phải mang lại các hợp đồng thông minh có thể lập trình được trong khi vẫn duy trì quyền tự quản lý : không bên trung gian nào có thể đóng băng hoặc tịch thu tiền của người dùng. Nó phải đạt được tất cả những điều này mà không cần thay đổi giao thức Bitcoin, không cần giới thiệu các bên trung gian đáng tin cậy có thể bị đánh cắp, và không cần buộc người dùng phải tin tưởng vào các buổi lễ ra mắt, các ủy ban và các nhà điều hành cầu nối mà họ không biết rõ lai lịch.

Mặc dù nhiều giải pháp mở rộng quy mô được đề xuất đã mở rộng chức năng của Bitcoin, nhưng chúng đã hy sinh bản chất phi tập trung của nó. Nhiều thiết kế dựa trên giả định tin cậy 1-trong-n, có nghĩa là bảo mật phụ thuộc vào việc ít nhất một người điều hành phải trung thực. Những thiết kế này làm tổn hại đến các nguyên tắc đạo đức cốt lõi của Bitcoin: phi tập trung và phi tập trung; chúng không phải là giải pháp mở rộng quy mô bền vững lâu dài cho Bitcoin .

KHỐI LẬP PHƯƠNG

Cube mang đến một phương pháp hoàn toàn khác đối với khả năng lập trình của Bitcoin : một Layer 2 gốc được thiết kế đặc biệt để thực thi các hợp đồng thông minh hoàn toàn không cần tin tưởng trực tiếp trên Bitcoin , mà không cần hợp đồng trung gian, liên minh nhà điều hành, hệ thống đồng thuận bên ngoài, hoặc thậm chí sửa đổi giao thức Bitcoin. Thay vì chuyển Bitcoin sang một lĩnh vực tin cậy khác để đổi lấy khả năng lập trình, Cube mở rộng mô hình tự quản lý và quyết toán của Bitcoin vào một hoàn cảnh thực thi có thể lập trình trong khi vẫn duy trì kết nối với mạng Bitcoin.

Mục tiêu cốt lõi của Cube từng được cho rằng mâu thuẫn trong hệ thống Bitcoin: lưu ký không cần tin tưởng và khả năng lập trình phổ quát. Hoàn cảnh hợp đồng thông minh truyền thống đạt được khả năng lập trình bằng cách trừu tượng hóa mô hình sở hữu và quyết toán của Bitcoin , thay thế chúng bằng các trình xác thực bên ngoài, hợp đồng bắc cầu, chữ ký đa chữ ký hoặc các giả định ký quỹ liên minh. Cube không làm điều này. Bên dưới lớp thực thi của Cube là mô hình sở hữu gốc của Bitcoin, cho phép các hợp đồng thông minh có thể lập trình hoạt động mà không làm mất đi khả năng rút lui đơn phương (tự lưu ký hoặc đảm bảo chuộc lại bắt buộc Bitcoin).

Cube tận dụng chính Bitcoin làm lớp quyết toán , giải quyết tranh chấp và quyền sở hữu cuối cùng trong hoàn cảnh thực thi. Hoàn cảnh hợp đồng thông minh hoạt động ngoài Chuỗi ở chế độ lạc quan, trong khi các đảm bảo quyết toán, lối thoát một chiều và việc thực thi các cơ chế phản hồi thách thức đều quay trở lại chính Bitcoin thông qua các thành phần cơ bản của Bitcoin.

Kiến trúc của Cube xoay quanh "Engine", một lớp điều phối chịu trách nhiệm tiếp nhận các giao dịch từ người tham gia, sắp xếp chúng thành lần và tạo ra các giao dịch quyết toán được gắn với mạng Bitcoin . Trong hoạt động bình thường, Engine tạo điều kiện thuận lợi cho việc chuyển đổi trạng thái và điều phối việc thực thi một cách lạc quan, mà không yêu cầu quyết toán ngay lập tức trên Chuỗi . Điều quan trọng là, Engine chỉ đơn thuần là một bộ điều phối, chứ không phải là người giám sát.

Mục tiêu thiết kế chính của Cube là khả năng lập trình không cần tin tưởng mà không làm mất đi đặc tính tự quản lý vốn có Bitcoin. Mỗi người tham gia luôn giữ quyền kiểm soát đơn phương đối với tiền của mình, thông qua các hạn chế được mô phỏng bởi chữ ký đa chữ ký MuSig2 và được thực thi trực tiếp bởi kịch bản Bitcoin. Tiền được khóa trong cấu trúc chữ ký đa chữ ký hợp tác 2-trên-2 (một-đối-một giữa người tham gia và Engine), tạo thành cơ sở nguyên tắc sở hữu chi phối hoàn cảnh thực thi của Cube.

Vì Cube không bao giờ trực tiếp quản lý tiền của người tham gia, nên Engine không thể tự mình chuyển tài sản, tịch thu số dư hoặc ngăn chặn việc rút tiền đơn phương. Người tham gia vẫn giữ khả năng thực thi các điều khoản rút tiền đơn phương trực tiếp trên mạng Bitcoin thông qua cơ chế quyết toán"cây hết thời gian chờ" và cơ chế phản hồi thách thức.

Do đó, Cube duy trì tính trung thực tuyệt đối ở cấp độ lưu ký trong khi mang khả năng lập trình hợp đồng thông minh tổng quát trực tiếp đến Bitcoin. Người tham gia không cần dựa vào tính toàn vẹn của các nhà điều hành, ủy ban, liên minh hoặc các trình xác thực bên ngoài để bảo vệ tiền của họ. Các đảm bảo về quyền sở hữu được thực thi trực tiếp bởi mã Bitcoin, các đường dẫn thoát một chiều và các cấu trúc phản hồi thách thức bằng mật mã. Engine không thể bị đánh cắp vì chính cấu trúc giao thức không cho phép điều đó; với các khóa và các đảm bảo chuộc lại được thực thi bằng Bitcoin, quyền kiểm soát tiền của người tham gia là không bị gián đoạn.

Quyền sở hữu điện toán ảo hóa

Kiến trúc thực thi của Cube là sự kết hợp của hai nguyên tắc cơ bản của Bitcoin: (1) ảo hóa quyền sở hữu cây thời gian chờ kiểu Ark; và (2) tính toán có thể bác bỏ kiểu BitVM.

Cây Thời Gian Hẹn (Timeout Tree) cung cấp quyền sở hữu ảo hóa có thể mở rộng và đảm bảo hoàn trả một chiều, cho phép người tham gia trao đổi đầu ra ảo ngoài Chuỗi trong khi vẫn duy trì khả năng tự động quay trở lại Chuỗi Bitcoin . BitVM bổ sung cho mô hình này bằng cách mở rộng quyền sở hữu ảo hóa sang tính toán ảo hóa, cho phép tính toán khả năng bác bỏ gốc của Bitcoin thách thức và thực thi các chuyển đổi trạng thái được khẳng định.

Cube kết hợp hai nguyên tắc cơ bản này thành một nguyên tắc thực thi thống nhất được gọi là " Hợp đồng khóa thời gian không tiết lộ thông tin (Zero-Knowledge Time-Locked Contracts - ZKLTC) ".

Về mặt khái niệm, (1) cây thời gian chờ giải quyết vấn đề ảo hóa quyền sở hữu; trong khi (2) BitVM giải quyết vấn đề tính toán bắt buộc. Cube kết hợp cả hai, do đó các chuyển đổi trạng thái có thể lập trình có thể xảy ra một cách lạc quan ngoài Chuỗi, đồng thời luôn duy trì khả năng chuộc lại và thách thức thông qua chính Bitcoin.

(Ghi chú của người dịch: "Lạc quan" ở đây có nghĩa là sự thay đổi trạng thái được đề xuất là hợp lệ trừ khi có người khác phản đối.)

Tóm lại, ZKTLC là một đầu ra ảo của cây thời gian chờ mang theo một khẳng định tính toán không tiết lộ thông tin, có thể được thực thi thông qua cơ chế thử thách của BitVM.

ZKTLCs

ZKTLCs mở rộng mô hình VTXO được sử dụng trong các hệ thống cây thời gian chờ kiểu Ark bằng cách bổ sung tính toán lập trình và ngữ nghĩa thách thức-phản hồi. Trong khi các VTXO truyền thống chủ yếu đại diện cho yêu cầu chuộc lại giá trị một chiều, ZKTLC còn đại diện cho một khẳng định tính toán có thể thách thức giữa người dùng và Engine. Do đó, đầu ra không chỉ là yêu cầu về giá trị mà còn là yêu cầu về tính đúng đắn của quá trình chuyển đổi trạng thái do Engine khẳng định.

Nói một cách trừu tượng, trong đó có thể được ví như các hợp đồng hai bên hiện có Bitcoin. Trong Mạng Lightning, một kênh chủ yếu là mối quan hệ một-đối-một giữa người dùng và Nhà cung cấp dịch vụ Mạng Lightning (LSP). Trong hệ thống kiểu Ark, một đầu ra ảo đại diện cho mối quan hệ một-đối-một giữa người dùng và nhà cung cấp dịch vụ Ark trong hệ thống đó. Và trong Cube, một ZKTLC đại diện cho mối quan hệ thách thức-phản hồi BitVM một-đối-một giữa người dùng và Engine.

Hoàn cảnh thực thi của Cube tuân theo mô hình thực thi của mô hình BitVM3 : trong trong đó các phép tính xác thực Groth16 được khẳng định được chuyển đổi thành hoàn cảnh xác thực mạch mã hóa có thể được thực thi thông qua cơ chế thách thức-phản hồi gốc Bitcoin . Các phép tính được khẳng định này tương ứng với các chuyển đổi trạng thái được hứa hẹn bởi Engine. Cụ thể hơn, Engine phải chứng minh rằng các chuyển đổi trạng thái được đề xuất được thực thi chính xác theo các quy tắc đồng thuận của (1) Bitcoin và (2) CubeVM, và không có chuyển đổi trạng thái không hợp lệ nào xảy ra so với các trạng thái đã hứa trước đó.

Thay vì thực hiện các phép tính tùy ý trực tiếp trên các nhà cung cấp Bitcoin, Cube thực hiện các xác nhận trình xác thực nhỏ gọn, tính đúng đắn của chúng có thể được kiểm chứng sau này trong hoàn cảnh kiểm chứng BitVM3. Do đó, mạch xác thực cơ bản thể hiện các quy tắc hợp lệ của hệ thống chuyển đổi trạng thái CubeVM, bao gồm ngữ nghĩa thực thi, ràng buộc hợp đồng, bất biến số dư , điều kiện hợp lệ chuyển đổi trạng thái và các quy tắc đồng thuận Bitcoin liên quan đến tính đúng đắn quyết toán .

Quá trình tính toán được khẳng định được biểu diễn bằng các bảng bị mã hóa, các cam kết nhãn dây, các bản ghi thử thách và một cấu trúc tiết lộ giá trị bí mật tương ứng với mạch xác thực. Trong quá trình thực thi hợp tác, hoàn cảnh phân xử vẫn ở trạng thái ngủ đông, và Engine lạc quan thúc đẩy các chuyển đổi trạng thái. Trong điều kiện đối kháng, một người tham gia có thể buộc tiết lộ các đầu vào có thể kiểm chứng được và có thể được đánh giá (bằng cách chứng kiến ​​chính sự khẳng định đó), tái tạo cục bộ một trình xác thực Groth16 bị mã hóa để có được cam kết, và sau đó tự đánh giá quá trình chuyển đổi trạng thái được khẳng định. Nếu quá trình đánh giá tạo ra kết quả không hợp lệ, trình xác thực bị mã hóa sẽ tạo ra một giá trị bí mật bác bỏ tương ứng với nhãn dây đầu ra bị lỗi, cho phép người tham gia kích hoạt một lộ trình quyết toán phạt liên quan đến các điều kiện khóa băm Bitcoin đã được cam kết.

Do đó, những người tham gia kiểm soát các đối tượng sở hữu ảo hóa bao gồm cả quyền chuộc lại đơn phương và quyền đối với trạng thái thực thi có thể cưỡng chế được khẳng định bởi Engine đã được chứng minh bằng mật mã.

Các hệ thống Bằng chứng không tri thức truyền thống dựa vào một nghi thức khởi tạo đáng tin cậy (hoặc ủy ban tính toán an bên long) liên quan đến toàn bộ hệ sinh thái. Cube khác biệt ở chỗ giới hạn hoàn cảnh chứng minh trong một hoàn cảnh độc lập cho mỗi người tham gia. Trong quá trình khởi tạo tài khoản, mỗi người tham gia trực tiếp làm việc với Engine để thực hiện một nghi thức khởi tạo riêng biệt, tạo ra các tham số chứng minh duy nhất, tham gia vào việc tạo ra chất thải độc hại và kiểm soát đốt chất thải độc hại của chính họ. (Ghi chú của người dịch: Ở đây, "chất thải độc hại" đề cập đến dữ liệu có thể làm rò rỉ thông tin liên quan đến nghi thức khởi tạo.)

Kết quả là, bằng cách tự khởi chạy thiết bị, tính không cần tin tưởng được lập trình sẵn cho người tham gia. Niềm tin không hướng đến ủy ban MPC bên ngoài, điều phối viên hoặc hoàn cảnh chứng cứ chung, mà chỉ giới hạn trong hoàn cảnhZKTLC của chính người tham gia.

Cây thời gian chờ

Cube sử dụng cây thời gian chờ làm kiến ​​trúc cơ bản về quyền sở hữu và thoát đơn phương, nằm ở cấp độ thấp hơn so với hoàn cảnh thực thi.

Cây thời gian chờ là một cây các giao dịch được ký trước cho phép lượng lớn các đối tượng sở hữu ảo hóa chia sẻ một cấu trúc quyết toán chung trong khi vẫn bảo vệ quyền chuộc lại đơn phương của mỗi người tham gia. Thay vì mọi chuyển giao quyền sở hữu trung gian quyết toán ngay lập tức trong Chuỗi Bitcoin , những người tham gia giao dịch một cách lạc quan trên đầu ra ảo hóa được nhúng trong một cây giao dịch chung.

Trong quá trình thực thi hợp tác, cây thời gian chờ vẫn ở trạng thái ngủ đông, và việc chuyển giao quyền sở hữu diễn ra ngoài Chuỗi . Nếu sự phối hợp thất bại, hoặc Engine trở nên không trung thực, các bên tham gia có thể độc lập hiện thực hóa và chuộc lại nhánh cây thời gian chờ tương ứng trong Chuỗi Bitcoin một khi các điều kiện thời gian chờ liên quan được đáp ứng.

Cube sử dụng cây thời gian chờ (timeout tree) làm cơ quyết toán và quyền sở hữu chính trong cơ chế thực thi ZKTLC . Số dư của mỗi người tham gia hệ thống cuối cùng có thể được quy đổi thành một đường dẫn chuộc lại theo cây thời gian chờ, có thể được thực thi thông qua một tập lệnh Bitcoin .

Về mặt khái niệm, cấu trúc cây thời gian chờ cung cấp cho Cube khả năng ảo hóa quyền sở hữu, trong khi ZKTLCs làm phong phú thêm các đối tượng quyền sở hữu này bằng khả năng tính toán lập trình và ngữ nghĩa phản hồi thách thức. Theo nghĩa này, kiến ​​trúc thực thi của Cube có thể được hiểu là sự kết hợp giữa quyền sở hữu ảo của Ark và khả năng tính toán có thể chứng minh được của BitVM, cả hai đều được neo trực tiếp vào các đảm bảo quyết toán của Bitcoin .

CubeVM

Cube giới thiệu một máy ảo tùy chỉnh có tên "CubeVM," là một phần mở rộng và bản sao của Bitcoin Script (một ngôn ngữ lập trình) được thiết kế đặc biệt để thực thi các hợp đồng thông minh không cần tin cậy trên Bitcoin. CubeVM không thay thế triết lý thực thi script của Bitcoin; thay vào đó, nó mở rộng hoàn cảnh thực thi dựa trên ngăn xếp của Bitcoin Script thành một hoàn cảnh trạng thái toàn cục có thể lập trình được, được tối ưu hóa cho các lối thoát một chiều và tính toán làm sai lệch.

CubeVM mở rộng Bitcoin Script với các mã lệnh bổ sung cần thiết cho việc tính toán hợp đồng thông minh tổng quát. Máy ảo này hỗ trợ nguyên bản quản lý trạng thái toàn cục, lưu trữ hợp đồng bền vững, hoàn cảnh thực thi biệt lập, quản lý bộ nhớ nâng cao, phép toán 256 bit, các phép toán đường cong elliptic, các phép toán phần tử ngăn xếp, ngữ nghĩa gọi hợp đồng và các mã lệnh chiếu trực tiếp thao tác với tài sản cơ bản , Bitcoin.

Không giống như các máy ảo gốc của tài khoản (như Máy ảo Ethereum(EVM)), CubeVM được thiết kế từ những nguyên tắc cơ bản (mang lại khả năng thực thi lập trình cho cơ chế tự lưu trữ gốc của Bitcoin). Do đó, các chuyển đổi trạng thái hợp đồng thông minh luôn tương thích với cấu trúc quyết toán cây thời gian chờ và chế độ làm sai lệch của Cube.

Điểm cốt lõi trong kiến ​​trúc của CubeVM là khả năng hỗ trợ " phép chiếu " (projection), cho phép liên tục chiếu số dư logic được kiểm soát bởi hợp đồng vào các đối tượng thoát đơn phương thuộc về những người tham gia. Thao tác chiếu đóng vai trò là cầu nối ngữ nghĩa giữa việc thực thi hợp đồng thông minh có thể lập trình và mô hình sở hữu dựa trên khóa của Bitcoin. Thông qua cơ chế này, CubeVM cho phép các hợp đồng thông minh có thể lập trình hoạt động trực tiếp trên Bitcoin trong khi vẫn duy trì đặc điểm chuộc lại đơn phương và tự quản lý được đảm bảo hoàn toàn trong quá trình thực thi hợp đồng.

phép chiếu

Các hệ thống hợp đồng thông minh có thể lập trình, chẳng hạn như Ethereum, hoạt động dựa trên mô hình sở hữu khác biệt hoàn toàn so với thiết kế gốc của Bitcoin. Trong Bitcoin, tiền được kiểm soát bởi các khóa công khai. Quyền sở hữu được thể hiện bằng khả năng tạo ra các chữ ký số hợp lệ, và tài khoản tự do thực hiện quyền ký sẽ quản lý số tiền đó. Hợp đồng thông minh thì hoàn toàn khác. Một hợp đồng thông minh không sở hữu quyền quyết định hay ý chí tự do vốn có trong một tài khoản. Nó được quản lý bởi chính nguồn vốn của hợp đồng, hoàn toàn bằng logic thủ tục xác định và các chuyển đổi trạng thái. Đặc biệt, chính logic của hợp đồng trở thành người giữ giá trị. Sự khác biệt này khiến cho mô hình sở hữu gốc của Bitcoin và ngữ nghĩa của các hợp đồng thông minh có thể lập trình về cơ bản là không tương thích.

Về cơ bản, BitVM và các mạch được làm mờ hoạt động trong bối cảnh hoàn cảnh dựa trên khóa. Các thành phần cơ bản của chúng xoay quanh khóa công khai, chữ ký, giao thức thách thức-phản hồi và các phép tính có thể chứng minh được liên kết sao chép lệnh. Mặc dù BitVM có thể xác minh các phép tính tùy ý, mô hình sở hữu cơ bản của nó vẫn không thay đổi: Bitcoin vẫn hiểu khóa, chứ không phải logic. Bản thân logic có thể thực thi không thể trực tiếp nắm giữ Bitcoin dưới dạng UTXO. Kết quả là, hai miền ngữ nghĩa riêng biệt xuất hiện. Bitcoin nói ngôn ngữ của khóa công khai, trong khi hợp đồng thông minh nói ngôn ngữ của logic. Các hệ thống này không tương thích tự nhiên vì Bitcoin thiếu một lớp trừu tượng gốc cho phép logic nắm giữ giá trị. Để khắc phục sự không tương thích này, công trình của chúng tôi giới thiệu một lớp trừu tượng trung gian: "phép chiếu".

Phép chiếu (Projection) là một lớp chuyển đổi nằm giữa mô hình lưu giữ gốc của logic và ngữ nghĩa nắm giữ gốc của Bitcoin. Thay vì biến chính logic thực thi thành một thực thể nắm giữ Bitcoin, nó cho phép số dư được kiểm soát bởi hợp đồng được chiếu thành một tập hợp số dư được liên kết với các khóa công khai thuộc về mỗi người tham gia. Quan sát cốt lõi đằng sau phép chiếu là mặc dù tiền có thể tạm thời nằm trong sự lưu giữ của logic hợp đồng, nhưng về mặt kinh tế, số tiền này vẫn thuộc về từng người tham gia trong suốt vòng đời của hợp đồng.

Thông thường, trong các hệ thống hợp đồng thông minh lập trình được như Ethereum, tiền di chuyển qua một chu kỳ lưu giữ định kỳ: ban đầu thuộc quyền sở hữu trực tiếp của một tài khoản, sau đó tạm thời thuộc quyền lưu giữ logic do hợp đồng kiểm soát, và cuối cùng, do rút tiền hoặc quyết toán, trở lại quyền sở hữu trực tiếp của tài khoản. Ban đầu, người tham gia có thể kiểm soát tiền thông qua số dư tài khoản được kiểm soát bởi khóa riêng của họ. Sau đó, người tham gia này có thể gửi số tiền này vào một hợp đồng thông minh—chẳng hạn như hợp đồng stablecoin được hỗ trợ bởi Bitcoin , nhóm thanh khoản nhà tạo lập thị trường tự động (AMM) hoặc một công cụ tài chính lập trình được khác—tại thời điểm đó, tiền không còn được nắm giữ trực tiếp bởi quyền ký của người tham gia nữa, mà hoàn toàn được điều chỉnh bởi logic thực thi và các quy tắc chuyển đổi trạng thái của hợp đồng. Cuối cùng, khi tài sản thế chấp được chuộc lại, thanh khoản được rút ra hoặc hợp đồng quyết toán, tiền sẽ trở lại quyền kiểm soát bằng khóa công khai của người tham gia. Do đó, vấn đề với quy trình này là, ở trạng thái trung gian, tiền không còn được kiểm soát trực tiếp bởi khóa công khai của người tham gia và do đó không thể được biểu thị là số dư được nắm giữ bởi khóa công khai vì chúng đang thuộc quyền lưu giữ logic. Trạng thái trung gian này, trạng thái được duy trì bởi logic, chính là nơi mà ngữ nghĩa quyền sở hữu gốc của Bitcoin và ngữ nghĩa thực thi gốc của hợp đồng thông minh không thể được đồng bộ hóa một cách tự nhiên.

(Ghi chú của người dịch: Trên thực tế, trên các giao thức như Ethereum, chỉ có đồng tiền gốc Ethereum là ETH mới có thể được nắm giữ trực tiếp bằng khóa công khai; các loại tiền tệ khác chỉ có thể được thao tác bằng khóa công khai theo logic thực thi của hợp đồng phát hành, có nghĩa là việc lưu giữ logic là chức năng chính.)

Phương pháp chiếu (projection) giải quyết sự không tương thích này bằng cách thể hiện nghĩa vụ của hợp đồng đối với các bên tham gia thay vì chính quyền quản lý hợp đồng. Số dư của hợp đồng được liên tục chiếu lên một tập hợp số dư tương ứng với số tiền cụ thể được nắm giữ bởi khóa công khai của người tham gia trong bất kỳ trạng thái hợp đồng nào (theo nghĩa kinh tế). Biểu diễn được chiếu này—trạng thái bóng (shadow state)—có thể được thể hiện bằng cấu trúc gốc Bitcoin, mặc dù quyền quản lý cơ bản của nó vẫn hoàn toàn được điều chỉnh bởi logic thực thi. Thông qua cơ chế này, các khoản tiền được quản lý bởi hợp đồng có thể được liên tục chiếu lên một cây thời gian chờ (timeout tree) được liên kết với khóa công khai của người tham gia, cho phép rút tiền đơn phương. Kết quả là, trong khi Bitcoin cơ bản vẫn được quản lý về mặt logic, người tham gia luôn giữ quyền chuộc lại số tiền cụ thể của họ trong bất kỳ trạng thái nào. Do đó, phương pháp chiếu đóng vai trò là cầu nối ngữ nghĩa giữa khung thử thách khóa gốc của BitVM và quyền quản lý logic dựa trên hợp đồng thông minh. Logic thực thi điều chỉnh các khoản tiền, nhưng trạng thái bóng của các khoản tiền này luôn có thể được chuộc lại thông qua cấu trúc khóa công khai gốc Bitcoin.

Không gian chiếu

Từ góc độ triển khai, cơ chế trừu tượng hóa phép chiếu tạo ra một không gian phân bổ chuyên dụng và được quản lý đúng cách gọi là " không gian chiếu ". Mỗi hợp đồng thông minh được triển khai trên Cube được gán một không gian chiếu riêng, đây là lớp sổ cái chịu trách nhiệm quản lý số dư bóng thuộc về các bên tham gia. Về mặt khái niệm, không gian chiếu là một cơ sở dữ liệu được phân bổ bởi chính hợp đồng, bao gồm một ánh xạ từ账户公钥-> 影子余额; trong đó mục nhập đại diện cho số lượng Bitcoin về mặt kinh tế thuộc về (hoặc "được nợ") tài khoản của người tham gia, mặc dù tiền tệ cơ bản được giữ trong tài khoản ký quỹ bởi hợp đồng. Do đó, không gian chiếu không đại diện cho quyền sở hữu tiền tệ dưới dạng UTXO; thay vào đó, nó đại diện cho trạng thái chuộc lại dự kiến ​​của thanh khoản do hợp đồng nắm giữ, hình thức của nó tương thích với khung khóa gốc và khung thoát đơn phương của BitVM. Việc phân bổ số dư bóng được tạo và quản lý bởi một tập hợp các mã lệnh chiếu chuyên dụng, cho phép các hợp đồng khởi tạo, tăng, giảm và điều chỉnh số dư thuộc về các bên tham gia trong quá trình thay đổi trạng thái.

Đối với mỗi tài khoản người tham gia, tổng của hai mục sau đây là:

1. Số dư ban đầu của tài khoản;
2. Các khoản phân bổ bóng (shadow allocations) thuộc về tài khoản này trên tất cả các hợp đồng;

Xác định số dư có thể quy đổi thực tế của người tham gia trên cây thời gian chờ ở bất kỳ trạng thái nào.

Điều quan trọng cần lưu ý là tổng số lượng phân bổ bóng (shadow allocation) cho một hợp đồng bị giới hạn nghiêm ngặt bởi số dư thực tế mà hợp đồng đó nắm giữ. Tổng số số dư bóng trong không gian chiếu của một hợp đồng không bao giờ có thể vượt quá số lượng Bitcoin hiện đang được hợp đồng đó nắm giữ: Contract Balance ≥ ∑Shadow Allocations

Bất kỳ hoạt động nào dẫn đến việc phân bổ số dư ảo vượt quá số dư Bitcoin thực tế của hợp đồng đều bị cho rằng không hợp lệ và bị từ chối ở cấp độ máy ảo. Ràng buộc này đảm bảo rằng tất cả số dư ảo dự kiến ​​luôn được đảm bảo đầy đủ bằng thanh khoản do hợp đồng nắm giữ, từ đó đảm bảo đủ thanh khoản rút tiền đơn phương cho tất cả số dư thuộc về người tham gia.

Mã lệnh chiếu

CubeVM tích hợp một tập hợp các mã lệnh độc quyền để quản lý không gian chiếu của một hợp đồng:

- Mã thao tác chiếu -

Các mã lệnh này cung cấp các nguyên tắc chuyển đổi trạng thái cần thiết để quản lý số dư bóng (shadow số dư) được phân bổ cho người tham gia trong quá trình thực thi hợp đồng. OP_SHADOW_ALLOC khởi tạo một mục phân bổ bóng mới cho tài khoản người tham gia trong không gian chiếu (projection space) của hợp đồng, với số dư ban đầu là 0. Sau khi phân bổ, OP_SHADOW_UP và OP_SHADOW_DOWN có thể được sử dụng để tăng hoặc giảm số dư phân bổ bóng liên quan đến người tham gia này.

Ví dụ, hãy xem xét một hợp đồng stablecoin được hỗ trợ bởi Bitcoin . Khi một người tham gia gửi Bitcoin vào hợp đồng này làm tài sản thế chấp, số tiền đã gửi được điều chỉnh bởi logic thực thi nội bộ của hợp đồng, chứ không còn bởi quyền ký của người tham gia nữa. Sau khi kiểm tra, hợp đồng gọi OP_SHADOW_UP để tăng phân bổ bóng (shadow allocation) của người tham gia bằng số lượng tài sản thế chấp tương ứng. Mặc dù Bitcoin đã gửi về mặt kỹ thuật nằm dưới sự quản lý logic của hợp đồng, một số dư tương đương trong số dư của người tham gia được chiếu vào một cây thời gian chờ (timeout tree) cho phép rút tiền đơn phương thông qua không gian chiếu (projection space). Điều này đảm bảo đủ thanh khoản rút tiền đơn phương, cho phép người tham gia luôn có thể rút tiền của họ, ngay cả khi tiền tệ cơ bản vẫn được ảo hóa và khóa trong hợp đồng. Đây là cơ chế cốt lõi của mô hình chuộc lại dựa trên khóa (key-native redemption model) và quản lý logic dựa trên hợp đồng thông minh của BitVM.

Ngoài các mã lệnh dựa trên tài khoản, CubeVM cũng bao gồm các mã lệnh được điều chỉnh theo tỷ lệ, bao gồm OP_SHADOW_UP_ALL và OP_SHADOW_DOWN_ALL . Không giống như OP_SHADOW_UP và OP_SHADOW_DOWN , chỉ thay đổi số dư của một người tham gia duy nhất, các mã lệnh này tăng hoặc giảm tỷ lệ phân bổ bóng của tất cả người tham gia trong không gian chiếu (dựa trên tỷ trọng tương đối hiện tại của họ). Các mã lệnh này đặc biệt hữu ích cho các hệ thống thanh khoản gộp như AMM. Khi thanh khoản Bitcoin gộp tăng hoặc giảm do giao dịch hoán đổi, phí hoặc các sự kiện thanh khoản, hợp đồng cần phải cân bằng tỷ lệ phân bổ bóng của tất cả nhà cung cấp thanh khoản trong việc thực thi một mã lệnh duy nhất, thay vì điều chỉnh phân bổ bóng của từng nhà cung cấp thanh khoản riêng lẻ. Điều này đơn giản hóa đáng kể độ phức tạp triển khai của các nguyên tắc tài chính gộp trong khi vẫn duy trì khả năng thoát ra một chiều được đảm bảo hoàn toàn cho tất cả người tham gia.

Máy chiếu

Cube sử dụng cấu trúc tổng hợp MuSig2 đã được sửa đổi như một cơ chế mô phỏng ràng buộc nhẹ (vì Bitcoin hiện thiếu các mã lệnh ràng buộc gốc). Thay vì dựa vào các nguyên thủy ràng buộc ở cấp độ giao thức, Cube sử dụng cấu trúc chữ ký tổng hợp được liên kết với giá trị để mô phỏng các ràng buộc; cấu trúc chữ ký tổng hợp này được gọi là "bộ chiếu".

Không giống như các chữ ký tổng hợp MuSig2 truyền thống, máy chiếu liên kết khóa công khai của điều khoản ràng buộc tổng hợp không chỉ với danh tính của người ký mà còn với một cam kết số cụ thể. Điều này liên kết về mặt mật mã khóa công khai của kịch bản điều khoản ràng buộc với trạng thái giá trị dự định.

Mục tiêu chính của trình chiếu là tạo ra một hoàn cảnh thực thi ràng buộc nhẹ, cho phép người tham gia thực hiện các phiên ký ràng buộc một cách an toàn mà không cần hiểu đầy đủ về trạng thái thực thi hợp đồng hoặc nội dung giao dịch. Người tham gia trình chiếu không cần phải phân tích vô số khả năng logic ràng buộc; họ có thể hoạt động an toàn bằng cách sử dụng càng ít xác minh xác định càng tốt, đồng thời vẫn chống lại các nỗ lực phát lại, liên kết lại và ký trùng lặp độc hại.

Nói một cách trừu tượng, máy chiếu biến đổi việc ký kết các điều khoản hạn chế thành một bài toán chiếu có ràng buộc: trạng thái hợp đồng có thể thực thi được chiếu vào một cấu trúc khóa công khai được liên kết với một giá trị, tương thích với chế độ thử thách gốc của BitVM dành cho khóa công khai.

Máy chiếu mở rộng quy trình tổng hợp MuSig2 ban đầu thông qua giai đoạn lập kế hoạch tiền xử lý: giai đoạn lập kế hoạch này được thực hiện trước các bước KeyAgg(pk_1 … pk_u) tiêu chuẩn (được định nghĩa bởi BIP-327 ).

Cube giới thiệu một hàm chiếu xác định liên kết giá trị (thay vì trực tiếp đưa khóa công khai của người tham gia vào hàm KeyAgg ):

 KeyProjectorAgg(pk_1...pk_u, val_1...val_u)

TRONG ĐÓ:

• pk_i là khóa công khai của người tham gia;
• val_i thể hiện giá trị cam kết tính bằng satoshi, được gắn liền với mỗi người tham gia.

Đối với mỗi người tham gia (được phân biệt bằng số i ), một hệ số điều chỉnh dự báo được tính như sau:

 t_i = H CubeProjector(val_i // i)

Trong đó, H CubeProjector biểu thị một hàm băm có nhãn, sử dụng nhãn "CubeProjector".

Sau đó, mỗi khóa công khai được biểu diễn như sau:

 pk_i'= pk_i + t_i.G

Bộ khóa công khai dự kiến ​​cuối cùng là:

 (pk_1', pk_2', ... , pk_u')

Sau đó, chúng được chuyển vào quy trình tổng hợp MuSig2 ban đầu:

 KeyAgg(pk_1', pk_2', ... , pk_u')

Quá trình ký MuSig2 còn lại không cần sửa đổi thêm. Về tính chính xác của chữ ký, mỗi người tham gia có thể sử dụng các điều chỉnh tương tự để dự đoán private key của mình:

 sk_i' = sk_i + t_i

Private key được dự kiến ​​sẽ được sử dụng trong quá trình tạo số ngẫu nhiên MuSig2 và tạo chữ ký phân mảnh còn lại, giống như trong giao thức gốc. Khóa công khai tổng hợp cuối cùng—được gọi là "khóa công khai dự kiến"—đồng thời được liên kết với danh tính của người ký và cam kết giá trị rõ ràng.

Thuộc tính ràng buộc giá trị này rất quan trọng đối với việc mô phỏng điều khoản hạn chế nhẹ. Trong cấu trúc MuSig2 tiêu chuẩn, tập hợp chỉ cam kết khóa công khai của người ký. Do đó, một điều phối viên độc hại có thể cố gắng ký nhiều trạng thái điều khoản hạn chế hợp lệ, miễn là người ký không hoàn toàn nhận thức được những gì họ đang ký.

Trong máy chiếu, cuộc tấn công này bị hạn chế đáng kể vì khóa công khai của điều khoản hạn chế tổng hợp tự thay đổi mỗi khi giá trị được hứa hẹn thay đổi. Vì khóa công khai của kịch bản điều khoản hạn chế được tạo ra từ khóa công khai tổng hợp được chiếu, nên quyền ký kết gắn liền với một trạng thái giá trị cụ thể. Do đó, ngay cả một hoàn cảnh ký kết chưa được xác minh đầy đủ cũng có thể tham gia một cách an toàn vào việc thực thi điều khoản hạn chế bằng cách chỉ chạy một lượng logic xác minh xác định tối thiểu.

chiếu hộp đơn vị chính

"Hosted Box Projection" đề cập đến một hoàn cảnh ký kết điều khoản hạn chế nhẹ với khả năng nhận thức ngữ cảnh hạn chế về biểu đồ thực thi điều khoản hạn chế rộng hơn. Về cơ bản, máy chủ (host box) là một dịch vụ mô phỏng điều khoản hạn chế nhẹ, luôn hoạt động trên thiết bị do người dùng kiểm soát, tương tự như bộ định tuyến, bộ lặp hoặc phần mềm nút hoạt động ngầm. Thiết bị này có thể do người tham gia vận hành hoặc được triển khai trên cơ sở hạ tầng lưu trữ bên ngoài, nhưng nhân vật của nó được xác định rõ ràng: tham gia vào phiên ký kết của máy chiếu khi Engine yêu cầu.

Máy chủ không phải là một hoàn cảnh thực thi hợp đồng thông minh hoàn chỉnh, mà chỉ là một nút mô phỏng hạn chế, chỉ chịu trách nhiệm tham gia vào quy trình ký kết của máy chiếu cho giá trị ràng buộc. Máy chủ không cần phải hiểu đầy đủ ngữ nghĩa của hợp đồng, luồng giao dịch, hoặc thậm chí cả nội dung thực thi. Nó chỉ cần tham gia một cách an toàn vào phiên ký kết của máy chiếu, một quy trình chỉ yêu cầu xác minh một vài thuộc tính xác định, chẳng hạn như:

• Cho dù khóa công khai của bạn có nằm trong tập hợp tổng hợp hay không, và
• Tham số máy chiếu ràng buộc giá trị được yêu cầu có hợp lệ không?

Sau khi các bước kiểm tra này thành công, máy chủ có thể tham gia an toàn vào quy trình ký MuSig2 còn lại tạo ra chữ ký phân mảnh cho khóa công khai tổng hợp dự kiến.

Tính bảo mật của mô hình này bắt nguồn từ việc tổng hợp chính giá trị ràng buộc. Bởi vì khóa công khai của kịch bản điều khoản hạn chế được liên kết mật mã với cam kết giá trị rõ ràng, các nỗ lực độc hại nhằm sử dụng lại quyền ký trong trạng thái điều khoản hạn chế thay thế sẽ chỉ tạo ra một khóa công khai tổng hợp của máy chiếu khác và một khóa công khai kịch bản điều khoản hạn chế hoàn toàn khác. Do đó, đơn vị máy chủ có thể hoạt động an toàn như một công cụ mô phỏng điều khoản hạn chế nhẹ mà không cần biết đầy đủ về việc thực thi điều khoản hạn chế; vì vậy, nó cũng phù hợp để đặt trong các thiết bị hoạt động liên tục, công suất thấp.

Chiếu hộp đen

Các máy chiếu cũng mở ra một lĩnh vực nghiên cứu rộng lớn trong tương lai được gọi là "Phép chiếu hộp đen". Trong mô hình này, hoàn cảnh ký mệnh đề hạn chế là một hệ thống đầu vào/đầu ra bị hạn chế, chỉ hiển thị càng ít trạng thái nội bộ, logic ký và ngữ nghĩa thực thi càng tốt, trong khi vẫn có thể tham gia một cách an toàn vào việc thực thi các mệnh đề hạn chế được ràng buộc với giá trị.

Vì các cam kết dự kiến ​​ràng buộc giá trị ở cấp độ ràng buộc, phép chiếu hộp đen có thể cho phép tham gia ràng buộc không tương tác: hoàn cảnh thời gian chạy ký không còn cần phải diễn giải hoặc xác minh đầy đủ bối cảnh thực thi liên quan, mà chỉ cần thực hiện các kiểm tra cấu trúc đơn giản nhất. Điều này sẽ làm cho quá trình mô phỏng ràng buộc trở nên mượt mà hơn nhiều, giảm độ phức tạp của các tương tác và mở ra khả năng về một hoàn cảnh thời gian chạy ký ràng buộc có khả năng mở rộng cao, nhẹ như một thiết bị chiếu mật mã bị ràng buộc (thay vì một bên tham gia thực thi hoàn toàn có trạng thái).

Hộp đen ảo

Một hướng đi khả thi là hoàn cảnh ký kết ràng buộc ảo biệt lập, hoạt động như một hộp đen đầu vào/đầu ra. Hệ thống như vậy có thể tham gia an toàn vào phiên ký kết của máy chiếu bằng cách thực hiện càng ít logic xác minh xác định càng tốt, chẳng hạn như xác minh nhóm người ký và xác minh rằng các tham số máy chiếu ràng buộc giá trị phù hợp với họ. Bởi vì khóa công khai tổng hợp của máy chiếu được ràng buộc giá trị, việc phát lại trên nhiều trạng thái ràng buộc hoặc các nỗ lực ký kép độc hại đã bị hạn chế. Điều này cho phép một hoàn cảnh ký kết được đơn giản hóa cao độ tham gia an toàn vào việc thực thi ràng buộc mà không cần biết đầy đủ về việc thực thi hợp đồng thông minh.

Hộp đen vật lý

Một hướng đi ít chắc chắn hơn là sử dụng các thiết bị hạn chế vật lý dạng "hộp đen". Lý tưởng nhất, một hệ thống như vậy sẽ cho phép chuyển giao thiết bị ký điện tử cho kẻ thù mà không bao giờ để lộ vật liệu private key bên trong, dù là để kiểm tra hay can thiệp.

Một kiến ​​trúc giả định có thể bao gồm việc lưu trữ private key dùng để ký trong một trường điện từ ổn định, bền vững hoặc trong một hoàn cảnh kín, cách ly chân không. Trong chế độ này, bất kỳ sự phát hiện vật lý, tháo dỡ hoặc can thiệp nào vào thiết bị đều sẽ phá hủy hoàn cảnh kín này, dẫn đến private key trong đó bị phá hủy. Mặc dù có vẻ hơi xa vời, nhưng hệ thống như vậy thể hiện một hướng đi dài hạn khả thi cho cơ sở hạ tầng ký kết điều khoản hạn chế: một hoàn cảnh ký kết bị giới hạn về mặt vật lý có khả năng tham gia một cách an toàn vào việc thực thi điều khoản hạn chế của máy chiếu trong khi vẫn duy trì sự cách ly mật mã mạnh mẽ.

nhảy

"Nâng cấp" là quá trình mà một UTXO Bitcoin Chuỗi được chuyển đổi một cách nguyên tử thành một đầu ra ảo gốc của Cube. Về mặt khái niệm, một bước nhảy "chuyển" Bitcoin từ quyền sở hữu trực tiếp Chuỗi hoàn cảnh thực thi ảo hóa của Cube, nơi mà tiền sau đó có thể tham gia hoàn cảnh các giao dịch chuyển khoản thông thường và các lệnh gọi hợp đồng thông minh.

Bitcoin phải thực hiện "nhảy" trước khi có thể lưu thông trong hệ thống Cube. Do đó, "nhảy" là cơ chế nhập chính thức để thanh khoản bên ngoài Chuỗi đi vào hoàn cảnh thực thi của Cube, duy trì quyền kiểm soát ở mọi bước của quy trình.

- Nhảy -

Đầu ra nhảy

Lift là một giao dịch đầu ra giới thiệu chuyên dụng được sử dụng để chuyển đổi Bitcoin thô trên Chuỗi thành đầu ra ảo gốc của Cube. Sau khi một đầu ra Lift được cấp vốn, những người tham gia và Engine của họ sẽ trao đổi nó lấy một VTXO tương ứng theo tỷ lệ 1:1 trong quá trình nhảy. Về cơ bản, Lift Lift được nâng cấp thành một đối tượng sở hữu ảo dạng cây thời gian chờ. Các đầu ra Lift có các điều kiện chi tiêu sau: (Self + Engine) or (Self after 3 months) :

• Đường dẫn nhảy : Người tham gia và Engine của họ cùng nhau ký kết thông qua đường dẫn Self + Engine . Đổi lại, người tham gia nhận được một VTXO tương ứng 1:1 trong hệ thống Cube.
• Đường thoát : Nếu Engine không hợp tác hoặc từ chối xử lý thao tác nhảy, người tham gia có thể tự lấy lại Bitcoin trong đó thông qua đường dẫn khôi phục sau khi hết thời gian chờ đã định.

Bậc thang bước thoát và xác minh fork

- Lối thoát đơn phương -

Trong trường hợp không hợp tác, tức là khi Engine từ chối hợp tác trong việc xử lý các yêu cầu rút tiền của người tham gia hoặc chấm dứt hợp đồng, Cube cung cấp một cơ chế rút lui đơn phương, đó là một loại giao dịch mang dữ liệu có tên là tx::exit-ladder .

Các bên tham gia có thể lựa chọn phương án rút lui đơn phương đối với một trong hai hình thức tài trợ này:

1. Rút trực tiếp số dư, chẳng hạn như các khoản mục hoán đổi chưa được giải quyết, và
2. Thoát khỏi số dư ảo được kiểm soát bởi hợp đồng thông qua đường dẫn thực thi Call -> Swapout .

Trong điều kiện bình thường, các hoạt động thoát này được xử lý cộng tác bởi các Engine tương ứng theo "lần". Nếu Engine từ chối bao gồm hoặc thực hiện hoạt động thoát do người tham gia yêu cầu, người tham gia có thể buộc thực hiện bằng cách phát đi giao dịch tx::exit-ladder trong Chuỗi.

Giao dịch tx::exit-ladder chứa dữ liệu mã hóa một thao tác thoát đang chờ xử lý mà Engine từ chối xử lý hợp tác. Cụ thể, giao dịch này mang một "Loại mục nhập" được mã hóa APE tương ứng với thao tác xử lý lần dự định thực hiện. Do đó, giao dịch thoát đơn phương này là một đường dẫn kháng nghị trong Chuỗi(nếu không, quá trình chuyển đổi trạng thái liên quan sẽ vẫn được ảo hóa ngoài Chuỗi).

Ngoài dữ liệu thoát ra, giao dịch tx::exit-ladder còn mang theo một điểm đầu ra "Connector" để "xác nhận fork".

Bộ kết nối này tồn tại để giải quyết một "vấn đề lựa chọn fork" cơ bản trong nhiều hợp đồng bắc cầu dựa trên BitVM và các kiến ​​trúc giải quyết tranh chấp: cả bên thách thức lẫn bên chứng minh đều không thể xác nhận một cách đáng tin cậy về Chuỗi chính thống mà trên đó quá trình chuyển đổi trạng thái gây tranh cãi thực sự đã xảy ra.

Nếu không có các nhân chứng như vậy, những kẻ điều hành độc hại có thể cố gắng tìm kiếm hoặc chuyển tiếp một fork thay thế không trung thực, đơn phương thoát khỏi giao dịch trên một fork không tồn tại, do đó né tránh cơ chế thách thức kích hoạt hoặc quy trình xử phạt của ZKTLC .

Cube ngăn chặn cuộc tấn công này bằng cách xuất ra các bằng chứng điểm một cách rõ ràng.

Đầu vào kết nối từ giao dịch tx::exit-ladder trở thành đầu vào cho giao dịch tx::fork-attest tương ứng. Vì đầu nối phải bắt nguồn từ chính giao dịch thoát đơn phương, nên Engine không thể xây dựng một đường dẫn chứng thực fork hợp lệ trên chuỗi xung đột nếu giao dịch `exit-ladder` này không tồn tại.

Do đó, sự tồn tại của các giao dịch rút lui đơn phương được liên kết về mặt mật mã với chính hoàn cảnh tranh chấp có thể thách thức. Engine không thể né tránh cơ chế thách thức kích hoạt bằng cách xác nhận có chọn lọc một Chuỗi fork khác chưa đưa ra yêu cầu rút lui đơn phương.

Giao dịch tx::fork-attest được xây dựng bằng kiến ​​trúc 2-of-2, được ký trước bằng thẻ SIGHASH_ALL | ANYONECANPAY , và bổ sung thêm đường dẫn xác minh SIGHASH_ALL CHECKSIG để đảm bảo rằng giao dịch bao gồm điểm đầu ra kết nối từ giao dịch tx::exit-ladder .

Cuối cùng, đường dẫn thoát đơn phương, được liên kết bởi các điểm đầu ra rõ ràng, chứng minh cho chuỗi mà nó thuộc về. Điều này cho phép người thách thức và người tham gia chứng minh một cách đáng tin cậy chuỗi tranh chấp dẫn đến lần cầu thoát đơn phương, ngăn chặn các cuộc tấn công lựa chọn fork không rõ ràng chống lại cơ chế phản hồi thách thức ZKTLC .

Mã hóa dữ liệu khả dụng

- So sánh phương pháp mã hóa -

Cube sử dụng định dạng mã hóa giao dịch tùy chỉnh có tên là " Airly Payload Encoding (APE) ", được thiết kế đặc biệt để tối ưu hóa hiệu quả khả năng truy cập dữ liệu của Cube.

Mục tiêu chính của APE là tối đa hóa mật độ giao dịch trong không gian khối Bitcoin bằng cách giảm thiểu chi phí mã hóa của mỗi giao dịch. Thông qua việc nén dữ liệu mạnh mẽ, lập chỉ mục nhỏ gọn và các chiến lược mã hóa dựa trên tổng hợp, Cube có thể xử lý nhiều chuyển đổi trạng thái hơn trong một khối Bitcoin(so với các kiến ​​trúc EVM hoặc zkEVM truyền thống).

Phương pháp mã hóa tổng quát, chẳng hạn như RLP, ưu tiên tính linh hoạt và biểu diễn cấu trúc đệ quy, nhưng APE được thiết kế đặc biệt cho việc thực thi tổng hợp xác định và mã hóa chuyển đổi trạng thái nhỏ gọn. Phương pháp mã hóa này giả định một hoàn cảnh thực thi bị ràng buộc với hệ thống kiểu được xác định trước, định dạng dữ liệu xác định và các đảm bảo ẩn từ lớp giao thức, cho phép Cube loại bỏ lượng lớn chi phí siêu dữ liệu cần thiết cho các hệ thống tương thích EVM truyền thống.

APE bao gồm một số kỹ thuật nén và mã hóa bổ sung cho nhau.

1. Mã hóa cấp bit

Cube sử dụng mã hóa cấp bit cho các trường giao dịch và kiểu dữ liệu số, thay vì sơ đồ mã hóa dựa trên byte truyền thống được sử dụng bởi các hệ thống EVM và zkEVM.

Các lược đồ mã hóa truyền thống, chẳng hạn như RLP , hoạt động ở cấp độ byte, có nghĩa là các giá trị được mở rộng thành các biểu diễn được căn chỉnh theo byte, ngay cả khi entropy thực tế của giá trị chỉ cần ít bit hơn để biểu diễn. Trong các tải trọng giao dịch lớn, điều này có thể dẫn đến chi phí tích lũy đáng kể.

APE loại bỏ giả định về sự căn chỉnh byte này và mã hóa trực tiếp các giá trị thành bit, dựa trên entropy thực tế của chúng chứ không phải độ rộng kiểu danh nghĩa.

Ví dụ, các hệ thống truyền thống sẽ:

• Sử dụng 4 byte để tuần tự hóa giá trị u32 (số nguyên 32 bit không dấu);
• Sử dụng 8 byte để tuần tự hóa giá trị u64 ;

Bất kể phạm vi biểu diễn thực tế là bao nhiêu. Tuy nhiên, trên thực tế, nhiều trường giao dịch, chẳng hạn như số chỉ mục, thẻ, bộ chọn, bộ đếm và các kiểu số nhỏ gọn, hiếm khi sử dụng hết toàn bộ không gian.

Do đó, APE tự động nén các trường này thành các biểu diễn byte nhỏ hơn, thông thường là:

• Điều này giúp tiết kiệm khoảng 1 đến 3 byte cho một giá trị u32 duy nhất.
• Điều này giúp tiết kiệm khoảng 1 đến 7 byte cho một giá trị u64 duy nhất.

Việc này chỉ phát sinh thêm từ 1 đến 2 bit chi phí phụ.

Vì Cube chỉ hoạt động trong hoàn cảnh thực thi xác định và bị ràng buộc bởi giao thức, và định dạng cũng như cấu trúc kiểu dữ liệu được gọi đã được biết trước, nên phương pháp này trở nên rất hiệu quả. Do đó, Cube có thể giảm đáng kể chi phí tuần tự hóa mà không cần cấu trúc dữ liệu tự mô tả đệ quy như RLP .

Xem: Các kiểu dữ liệu số .

2. Chỉ số dựa trên thứ hạng

Cube lập chỉ mục các tài khoản và hợp đồng dựa trên tần suất giao dịch chứ không phải thứ tự đăng ký.

Lần một tài khoản thực hiện giao dịch hoặc một hợp đồng được kích hoạt, điểm số của nó sẽ tăng lên 1. Theo thời gian, các tài khoản và hợp đồng được truy cập thường xuyên sẽ nhận được chỉ số thấp hơn.

Điều này cho phép các thành phần cơ bản của hệ thống được sử dụng rộng rãi—như các nhóm AMM, hợp đồng stablecoin và các trung tâm thanh khoản lớn—cuối cùng được nén thành các biểu diễn chỉ mục rất nhỏ, thường cho phép định địa chỉ bằng một byte.

Hệ thống xếp hạng và lập chỉ mục này được duy trì trong bộ nhớ và ở lớp thực thi, do đó Cube có thể tránh việc truyền đi truyền lại các định danh tĩnh lớn, chẳng hạn như địa chỉ EVM 20 byte hoặc định danh hợp đồng có độ dài cố định.

Xem: Quản lý đăng ký .

3. Dữ liệu cuộc gọi không có tiền tố

Cube ánh xạ trực tiếp các phần tử dữ liệu đến các định dạng kiểu được xác định trước, mỗi định dạng có độ dài xác định.

Do đó, các phần tử dữ liệu cuộc gọi không yêu cầu phương pháp mã hóa đệ quy rõ ràng để thêm tiền tố là độ dài số vào dữ liệu (phương pháp trong RLP). Vì bộ giải mã đã biết cấu trúc dự kiến ​​và độ rộng trường của định dạng dữ liệu cuộc gọi, nên dữ liệu tiền tố bổ sung trở nên không cần thiết.

Điều này loại bỏ chi phí tiền tố vốn luôn gắn liền với việc tuần tự hóa dữ liệu cuộc gọi EVM, đồng thời đơn giản hóa việc phân tích cú pháp tải trọng xác định.

Xem phần tử Calldata để biết chi tiết.

4. Bảng tra cứu số thông dụng

Cube sử dụng cơ chế mã hóa dựa trên