Con đường hướng tới tính toán phổ quát trên Bitcoin: Thiết kế STARK để mở rộng quy mô cho Bitcoin
Tuyển chọn TechFlowTuyển chọn TechFlow
Con đường hướng tới tính toán phổ quát trên Bitcoin: Thiết kế STARK để mở rộng quy mô cho Bitcoin
Bài viết này sẽ thảo luận về nhiệm vụ triển khai tính toán phổ quát trên Bitcoin và các bước liên quan.
Chuyên sâu báo cáo Web3Tác giả: StarkWare
Biên dịch: Cộng đồng tiếng Trung Starknet
1. Mở đầu
Trong bài viết này, chúng ta sẽ thảo luận về việc thực hiện tính toán phổ quát trên Bitcoin và các bước liên quan. Thực tế, việc đạt được khả năng tính toán logic tùy ý trên tập lệnh Bitcoin là một mục tiêu hấp dẫn, bởi vì nó đưa Bitcoin vào lĩnh vực ứng dụng phi lưu ký và tài chính phi tập trung.
Trước đây, do hai hạn chế nghiêm trọng — độ dài tập lệnh Bitcoin và khả năng biểu đạt của mã vận hành — tính toán phổ quát trên Bitcoin gần như được coi là bất khả thi. Hạn chế đầu tiên cấm mọi giao dịch ngoài các tập lệnh ngắn, trong khi hạn chế thứ hai giới hạn nội dung mà mã vận hành tập lệnh có thể tính toán. Hai giới hạn này cùng nhau tạo thành một tình trạng nghiêm trọng đối với khả thi tính toán trên Bitcoin, vì nhiều ứng dụng không thể triển khai dưới những điều kiện này.
Tuy nhiên, trong những năm gần đây, tình hình đã cải thiện đáng kể. Thực tế, với nâng cấp Taproot năm 2021, giới hạn độ dài tập lệnh đã được dỡ bỏ, cho phép tập lệnh Bitcoin trở nên đáng kể dài hơn (thực tế, tập lệnh Taproot thậm chí cho phép đôi khi chỉ thanh toán trên chuỗi cho một phần của tập lệnh, nhưng chúng ta sẽ không đề cập đến đặc điểm này trong bài viết). Ngoài ra, để giải quyết giới hạn về khả năng biểu đạt của mã vận hành, chúng ta phát hiện ra rằng chỉ cần một mã vận hành đơn giản là đủ để hiệu quả đạt được khả năng biểu đạt vô hạn.
Mã vận hành nói trên được gọi là OP_CAT, bị vô hiệu hóa trong tập lệnh Bitcoin từ năm 2012. Đây là một mã vận hành rất đơn giản, cho phép nối các phần tử trên ngăn xếp, và chỉ cần 13 dòng mã để kích hoạt một cách không xâm lấn thông qua phân nhánh mềm trên Bitcoin. Việc rút ra sức mạnh lớn lao từ một mã vận hành tưởng chừng tầm thường như vậy là điều không dễ dàng, do đó mục tiêu cốt lõi của bài viết này là trình bày chi tiết điều này.
Tiếp theo, chúng ta sẽ đi sâu vào quá trình tính toán trên Bitcoin, bắt đầu từ cách thức thực hiện và các hạn chế tồn tại.
Sau đó, chúng ta sẽ phác thảo hai công cụ — Covenant và bằng chứng STARK — và chứng minh rằng nếu cả hai có thể chạy trong tập lệnh Bitcoin, chúng sẽ cho phép tính toán phổ quát trên Bitcoin. Hơn nữa, trong bài viết này, chúng ta sẽ lập luận rằng nhờ vào bằng chứng STARK, loại tính toán này còn có thể được trang bị thêm các thuộc tính hữu ích:
-
Mở rộng quy mô — xử lý giao dịch và tính toán trên chuỗi trở nên khả thi với phí cực thấp.
-
Khả năng biểu đạt — logic có thể được lập trình bằng các ngôn ngữ khác mạnh hơn tập lệnh Bitcoin. Điều này rất quan trọng đối với tính thân thiện và an toàn trong lập trình Bitcoin.
-
An toàn trên chuỗi — bất kể tính toán nào, tập lệnh Bitcoin chỉ xác minh bằng chứng toán học về tính toán được ủy quyền.
-
Tính linh hoạt — tính toán trên Bitcoin có thể lưu trữ trạng thái toàn cục, cho phép triển khai nhiều ứng dụng.
Cuối cùng, chúng ta sẽ thảo luận về OP_CAT và cách nó cho phép thực hiện các công cụ nêu trên. Chúng ta cũng sẽ đề cập đến một số nỗ lực của chúng tôi trong lĩnh vực này và thảo luận về hướng phát triển trong tương lai.
Lưu ý: Bài viết này đơn giản hóa một số vấn đề kỹ thuật nhằm cung cấp một mô hình tư duy rõ ràng. Khi áp dụng thực tế các ý tưởng được trình bày, "chi tiết là yếu tố quyết định thành bại".
2. Mô hình UTXO và tập lệnh khóa
Trong phần này, chúng ta sẽ tóm tắt ngắn gọn mô hình UTXO của Bitcoin, tức là mỗi UTXO đều bị khóa đằng sau một tập lệnh khóa. Nếu bạn đã quen thuộc, có thể chuyển sang phần tiếp theo.
Bước đầu tiên để hiểu giao dịch Bitcoin là nhận thấy chúng được tổ chức và xử lý theo mô hình đầu ra giao dịch chưa chi tiêu (UTXO), như minh họa ở Hình 1. Giao dịch Bitcoin có thể có nhiều đầu vào và đầu ra, trong đó mỗi đầu ra đại diện cho một lượng Bitcoin nhất định có thể bị chi tiêu bởi một giao dịch khác. Tương ứng, đầu vào của một giao dịch đại diện cho việc chi tiêu đầu ra của một giao dịch Bitcoin khác. Tất nhiên, chúng ta yêu cầu tổng lượng Bitcoin ở đầu vào xấp xỉ bằng tổng lượng ở đầu ra (chênh lệch là phí trả cho thợ đào).
Hình 1: Giao dịch trong mô hình UTXO. Mỗi đầu vào và đầu ra của giao dịch liên kết với một lượng Bitcoin nhất định, trong đó tổng lượng ở đầu ra không được vượt quá tổng lượng ở đầu vào. Các đầu ra giao dịch chưa chi tiêu (UTXO) được biểu thị bằng màu xanh lam.
Mỗi đầu ra giao dịch bị khóa bởi một tập lệnh khóa (scriptPubKey), tập lệnh này chấp nhận hoặc từ chối đầu vào (scriptSig) được cung cấp (bởi người gọi là người chi tiêu). Do đó, nếu muốn chuyển tiền từ một đầu ra giao dịch chưa chi tiêu (UTXO), bạn phải có khả năng tạo ra scriptSig đúng và bao gồm UTXO này làm đầu vào trong giao dịch bạn tạo.
Theo mặc định, tập lệnh khóa đơn giản kiểm tra chữ ký số dựa trên khóa công khai được mã hóa cứng, định nghĩa sở hữu của Bitcoin bị khóa. Tổng quát hơn, bất cứ khi nào tồn tại một UTXO, chúng ta có thể nói rằng người có thể cung cấp scriptSig đúng là chủ sở hữu của lượng Bitcoin bị khóa phía sau tập lệnh khóa tương ứng. Do đó, tổng số dư của mỗi chủ sở hữu Bitcoin được tích lũy từ tất cả các UTXO liên quan đến chủ sở hữu đó (ví dụ: tất cả UTXO được ký số bởi cùng một người).
3. Những hạn chế của tập lệnh Bitcoin
Phần trước đã phác thảo tình huống chung về tập lệnh khóa và cách chúng tương tác với giao dịch Bitcoin và bản thân Bitcoin. Phần này, chúng ta sẽ tập trung vào bản thân tập lệnh khóa và nội dung cấu thành nó.
Tập lệnh khóa trên Bitcoin được viết bằng một ngôn ngữ dựa trên ngăn xếp tương tự Forth, được gọi là "tập lệnh Bitcoin". Vì tập lệnh Bitcoin không có vòng lặp, chúng ta đo chi phí tập lệnh bằng số lượng mã vận hành cần thiết, do độ dài tập lệnh tỷ lệ thuận với thời gian chạy. Trong Hình 2, chúng ta có thể thấy sơ đồ của một chương trình đơn giản kiểm tra xem tổng hai đầu vào có bằng 12 hay không.
Hình 2*: Một chương trình đơn giản kiểm tra xem tổng hai giá trị đầu vào có bằng 12 hay không. Việc thực thi chương trình được thực hiện bằng cách nối scriptSig với bản thân tập lệnh khóa, sau đó xử lý các mã vận hành từ trái sang phải. scriptSig chỉ đẩy các phần tử vào ngăn xếp. (a) Bước đầu tiên của tính toán. (b)* Trong quá trình tính toán. (c) Bước cuối cùng của tính toán (tập lệnh khóa chấp nhận đầu vào).
Chúng ta phải chỉ ra rằng tập lệnh Bitcoin có rất nhiều hạn chế, khiến việc phát triển logic đơn giản trở nên cực kỳ khó khăn, thậm chí là bất khả thi. Những hạn chế này bao gồm:
-
Giới hạn ngăn xếp tối đa 1000 phần tử.
-
Không có mã vận hành nhân (thực tế, ngay cả phép nhân số nguyên 31 byte cũng cần khoảng 14.000 mã vận hành để mô phỏng).
-
Đối với loại đầu ra Pay2Taproot (sau nâng cấp Taproot), tổng số mã vận hành trong một giao dịch tối đa khoảng 4 triệu, chiếm đầy cả khối; đối với các loại đầu ra khác, tổng số mã vận hành chỉ là 10.000.
-
Phép toán số học (cộng, trừ) bị giới hạn ở các phần tử 4 byte.
Giới hạn 4 byte được nhắc đến ở điểm cuối cùng đặc biệt gây vấn đề. Thực tế, điều này có nghĩa là bạn không thể sửa đổi các phần tử dài, ví dụ như các phần tử 20 byte hoặc dài hơn cần cho các thao tác mã hóa.
Ví dụ, thao tác rất phổ biến như nối dữ liệu lại với nhau rồi áp dụng thao tác mã hóa là không thể thực hiện, trừ khi bỏ qua các mã vận hành mã hóa và mô phỏng chúng như các thao tác trên dữ liệu được biểu diễn bởi mảng các phần tử 4 byte. Chi phí của phương pháp sau cực kỳ cao, vì một thao tác băm đơn lẻ có thể cần hàng trăm ngàn mã vận hành để mô phỏng.
Cuối cùng, chúng ta cần chỉ ra rằng do việc phát triển tập lệnh Bitcoin rất khó, mã nguồn tự nhiên dễ mắc lỗi và lỗ hổng hơn.
4. Thách thức trong việc lưu trạng thái bằng tập lệnh Bitcoin
Mặc dù phần trước đã chứng minh tập lệnh Bitcoin còn nhiều thiếu sót, chúng tôi cho rằng hạn chế lớn nhất của tập lệnh khóa Bitcoin nằm ở chỗ nó chỉ có thể đọc đầu vào từ người chi tiêu. Điều này dẫn đến hai hạn chế nghiêm trọng:
-
Tập lệnh Bitcoin không có trạng thái. Nghĩa là, chúng không thể đọc/ghi dữ liệu từ các ô nhớ. So sánh với Máy ảo Ethereum, không có mã vận hành tương tự SLOAD/SSTORE, trong khi đây là chức năng cơ bản để thực hiện tính toán phổ quát.
-
Tập lệnh Bitcoin không thể buộc cách chi tiêu Bitcoin (ngoại trừ một vài ngoại lệ). Điều này có thể được giải quyết bằng Covenant, công cụ này trao cho tập lệnh khóa khả năng đó. (Bạn có thể hình dung một ứng dụng đơn giản như kho bạc trên chuỗi, hoạt động bằng cách giới hạn địa chỉ được phép chi tiêu. Nói chung, Covenant là một công cụ cực kỳ mạnh mẽ với phạm vi ứng dụng rộng rãi.)
Sau đó, chúng ta sẽ thấy rằng bằng cách xây dựng Covenant, chúng ta đã có thể đạt được trạng thái. Về trực giác, điều này là do bạn có thể sử dụng Covenant để mô phỏng việc đọc và ghi bộ nhớ trong chính dữ liệu giao dịch.
Thật ra, những gì được nêu trên vẫn chưa đủ để bao quát toàn bộ nội dung và sự phức tạp của tập lệnh Bitcoin. Nhưng ít nhất, chúng ta có thể chắc chắn rằng viết tập lệnh Bitcoin không hề dễ dàng. Tập lệnh Bitcoin có những giới hạn rất nghiêm ngặt:
-
Giới hạn ngăn xếp không được vượt quá 1000 phần tử.
-
Phải dùng nhiều mã vận hành để mô phỏng các thao tác đơn giản như phép nhân. Nói chung, bạn phải viết logic bằng ngôn ngữ tập lệnh Bitcoin rườm rà.
-
Phải thao tác với các phần tử được mã hóa dạng 4 byte. Đặc biệt, bạn không thể thao tác hoặc thay đổi đầu vào cho các mã vận hành mã hóa.
-
Logic của bạn không thể lưu trạng thái và phải thích nghi với một giao dịch đơn lẻ.
-
Sau khi xác thực, logic của bạn không thể kiểm soát cách chi tiêu Bitcoin.
Ngoài ra, việc viết mã theo các giới hạn trên dễ dẫn đến lỗi và lỗ hổng.
Mặc dù các ứng dụng rất đơn giản như thanh toán có thể đáp ứng các giới hạn trên, nhưng bất kỳ ứng dụng nào phức tạp hơn một chút đều gặp trở ngại. Tiếp theo, chúng ta sẽ tìm hiểu cách Covenant và bằng chứng STARK giúp chúng ta phá vỡ những giới hạn này. Ngoài ra, chúng ta cũng sẽ thảo luận về cách OP_CAT giúp tập lệnh Bitcoin đạt được các chức năng nêu trên.
5. Thực hiện hợp đồng thông minh trên Bitcoin thông qua Covenant
Trong phần này, chúng ta sẽ tìm hiểu cách Covenant trong Bitcoin lưu trạng thái logic và giải thích tổng quát hơn, một "hợp đồng thông minh" trên Bitcoin trông như thế nào. Ở đây, hợp đồng thông minh ám chỉ một loại logic có trạng thái, bao gồm một loạt hàm có thể được gọi theo các quy tắc đã định trước để chuyển trạng thái sang các trạng thái hợp lệ khác.
Cụ thể hơn, hợp đồng Bitcoin cần các chức năng sau:
-
Logic và trạng thái bền vững
-
Khả năng kiểm soát thay đổi logic/trạng thái
Như đã nói, các chức năng trên có thể đạt được thông qua Covenant. Nhắc lại, theo mặc định, tập lệnh khóa chỉ có thể đọc dữ liệu đầu vào trực tiếp (scriptSig). Tuy nhiên, với Covenant, tập lệnh khóa có thể đọc tất cả các trường dữ liệu của giao dịch người chi tiêu, cũng như các trường dữ liệu của giao dịch chứa tập lệnh khóa, thậm chí cả dữ liệu của các giao dịch khác. Hình 3 minh họa các phần khác nhau mà tập lệnh khóa có thể truy cập khi sử dụng Covenant.
Hình 3: Một số trường dữ liệu mà tập lệnh khóa (được hình dung như một ổ khóa) có thể truy cập (được hiển thị bằng mũi tên đỏ). Ngoài việc truy cập các trường dữ liệu của giao dịch người chi tiêu, tập lệnh khóa còn có thể truy cập các trường dữ liệu của giao dịch chứa nó (tx1) và các trường dữ liệu của một giao dịch khác (tx2) cũng bị chi tiêu đồng thời bởi giao dịch người chi tiêu.
Chúng tôi cho rằng Covenant được mô tả ở trên là đủ để xây dựng hợp đồng thông minh phổ quát trên Bitcoin. Thực tế, phương pháp chung là mã hóa trạng thái trong chính dữ liệu giao dịch và kiểm tra tính hợp lệ của việc chuyển đổi sang giá trị mới. Để thực hiện điều này, giao dịch của chúng ta sẽ có hai đầu ra:
-
Đầu ra đầu tiên lưu logic hợp đồng (qua tập lệnh khóa) và tiền được khóa trong hợp đồng.
-
Đầu ra thứ hai lưu trạng thái hiện tại của hợp đồng thông minh. UTXO này có tập lệnh khóa chỉ lưu trạng thái và sẽ không bao giờ bị chi tiêu (lượng Bitcoin bị khóa thực tế là 0).
Logic tập lệnh khóa sẽ thực thi các quy tắc sau:
-
Giao dịch người chi tiêu phải có dạng hoàn toàn giống nhau (chỉ có hai đầu ra và tất cả tiền bị khóa ở đầu ra đầu tiên);
-
Đầu ra đầu tiên phải có logic tập lệnh khóa giống hệt;
-
Đầu ra thứ hai phải là trạng thái hợp lệ;
-
Đầu vào cung cấp cho tập lệnh khóa hiện tại phải thuyết phục tập lệnh khóa rằng việc chuyển đổi từ trạng thái hiện tại sang trạng thái mới là hợp lệ (tính hợp lệ do người thiết kế logic định nghĩa)
Hình 4 là sơ đồ của cấu trúc này. Như Weikeng Chen đã viết, nhiều người đã đề xuất đặt tên chính thức cho cấu trúc này, và "state caboose" được nổi bật như một ứng cử viên. Caboose là toa xe nối ở cuối đoàn tàu hàng, nơi dành cho nhân viên đường sắt và không gian làm việc của họ.
Hình 4: Hợp đồng thông minh được thực hiện trên Bitcoin thông qua Covenant, tuân theo mô hình thiết kế "state caboose". Tập lệnh khóa đảm bảo giao dịch người chi tiêu có dạng và tập lệnh khóa giống nhau, và có trạng thái mới S' hợp lệ, việc chuyển đổi từ trạng thái trước S cũng hợp lệ.
Ví dụ đơn giản, bạn có thể hình dung một hợp đồng thông minh đếm đơn giản. Trạng thái của hợp đồng luôn tăng theo giá trị do người chi tiêu cung cấp, thực tế gọi một hàm "tích lũy". Hợp đồng thông minh đếm này được minh họa trong Hình 5.
Hình 5: Một hợp đồng thông minh đơn giản, cộng dồn đầu vào (scriptSig) vào trạng thái của nó.
Cuối cùng cần lưu ý rằng để "gọi hợp đồng" và chuyển hợp đồng sang trạng thái hợp lệ mới, người dùng cần tạo một giao dịch người chi tiêu mới cho mỗi lần gọi. Khác với hợp đồng thông minh Ethereum, hợp đồng thông minh Bitcoin về bản chất là tuần tự, yêu cầu giao dịch cam kết đồng thời trạng thái hiện tại và trạng thái mới. Khi xây dựng hợp đồng thông minh trên Bitcoin, phải tính đến thuộc tính tuần tự này. Mặc dù tồn tại một số phương án có thể làm giảm nhẹ hạn chế này, nhưng bài viết sẽ không đi sâu vào.
Tổng thể, chúng ta hiểu rằng Covenant cho phép thực hiện hợp đồng thông minh trên Bitcoin, về mặt lý thuyết, khi tính toán được chia nhỏ thành đủ nhiều giao dịch, có thể thực hiện tính toán độ dài tùy ý trên Bitcoin. Tuy nhiên, chỉ dùng Covenant vẫn chịu hầu hết các hạn chế của tập lệnh Bitcoin, tức là giới hạn kích thước ngăn xếp, số lượng mã vận hành bị giới hạn, và nói chung phải lập trình theo các ràng buộc của ngôn ngữ tập lệnh Bitcoin.
Tiếp theo, chúng ta sẽ khám phá cách hệ thống xác minh STARK có thể giảm thiểu mức chiếm dụng blockchain của tính toán trên Bitcoin và cho phép sử dụng ngôn ngữ hoàn toàn khác để viết tập lệnh, từ đó giảm nhẹ các hạn chế trên. Phương pháp này nâng cao đáng kể hiệu quả và an toàn trong lập trình.
6. Bộ xác minh STARK trên Bitcoin
Mục đích của phần này là khám phá cách thực hiện tính toán trên Bitcoin trong khi giảm thiểu mức độ tính toán thực tế qua tập lệnh Bitcoin xuống mức thấp nhất. Phương pháp chung của chúng ta là thông qua ủy quyền tính toán, tức là chuyển tính toán ra khỏi chuỗi (nhiều thực thể có thể tham gia), chỉ bước xác minh được thực hiện trong tập lệnh Bitcoin trên chuỗi.
Điều này dẫn đến câu hỏi: Làm sao để đảm bảo tính toán ngoài chuỗi được thực hiện đúng? Thực tế, một ứng cử viên tự nhiên để giải quyết vấn đề này là hệ thống chứng minh. Nói đơn giản, hệ thống chứng minh cho phép Alice (người chứng minh) thuyết phục Bob (người xác minh) về tính đúng đắn của một mệnh đề bằng cách cung cấp một "bằng chứng", với điều kiện then chốt là:
-
Người xác minh hoàn thành ít công việc hơn so với khi không có sự giúp đỡ của người chứng minh để xác minh mệnh đề.
-
Hơn nữa, người xác minh được bảo vệ sao cho người chứng minh không thể lừa người xác minh tin vào một mệnh đề sai.
Mệnh đề được chứng minh có thể là bất kỳ mệnh đề nào, từ lời giải cho một bài toán khó đến ví dụ ủy quyền tính toán liên quan hơn. Cụ thể hơn, Alice sẽ chứng minh với Bob rằng f(x)=y, mà không yêu cầu Bob tự thực hiện phép tính f(x), như minh họa ở Hình 6.
Hình 6: Hệ thống chứng minh cho ủy quyền tính toán. Người chứng minh tính y=f(x) và thuyết phục người xác minh về tính đúng đắn của mệnh đề này. Điểm then chốt là nếu y≠f(x), người chứng minh không thể thuyết phục người xác minh tin điều đó.
Do đó, phương pháp giảm mức chiếm dụng tính toán trên blockchain của chúng ta là thực hiện một bộ xác minh hệ thống chứng minh trong tập lệnh Bitcoin. Vì vậy, để gọi hợp đồng thông minh, người gọi sẽ cung cấp bằng chứng về việc chuyển đổi trạng thái đúng, và hợp đồng thông minh Bitcoin sẽ xác minh tính đúng đắn của bằng chứng chuyển đổi trạng thái này, thay vì trực tiếp kiểm tra việc chuyển đổi trạng thái (xem Hình 7).
Hơn nữa, phương pháp này còn có lợi ích then chốt là logic tập lệnh Bitcoin có thể giữ nguyên cố định, không phụ thuộc vào ứng dụng, điều này giảm đáng kể khả năng xảy ra lỗi và đơn giản hóa việc kiểm toán. Điều này bắt nguồn từ một thực tế đơn giản: cùng một thuật toán xác minh có thể xác minh mệnh đề y=f(x) hoặc y=g(x) mà không cần biết trước hàm cần tính.
Hình 7: Hợp đồng thông minh được thực hiện trên Bitcoin thông qua Covenant, tuân theo mô hình thiết kế "state caboose" trong Hình 4, nhưng thêm một bộ xác minh. Lần này, tập lệnh khóa không còn trực tiếp kiểm tra việc chuyển đổi từ S sang S' có hợp lệ hay không, mà xác minh bằng chứng về tính đúng đắn của việc chuyển đổi.
Mặc dù tồn tại nhiều hệ thống chứng minh, chúng tôi chọn sử dụng hệ thống chứng minh STARK (STARK) vì nó có nhiều đặc điểm hấp dẫn:
-
An toàn hậu lượng tử
-
Không cần thiết lập đáng tin cậy
-
Không thêm giả định mật mã mới cho Bitcoin
-
Tốc độ mở rộng nhanh nhất
-
Đã được kiểm nghiệm thực tiễn, được tin cậy trong thanh toán vượt quá một nghìn tỷ đô la
Cuối cùng, so với các hệ thống chứng minh khác⬇️
STARK thân thiện với Bitcoin, tức là thành phần bộ xác minh của nó dễ thực hiện hơn trong tập lệnh Bitcoin. Về bản chất, điều này là do STARK chủ yếu dựa trên hàm băm, với rất ít thao tác đại số so với các hệ thống chứng minh dựa trên ghép cặp.
Chi phí thao tác đại số trong tập lệnh Bitcoin rất cao, điều này giải thích tại sao STARK thân thiện với Bitcoin. Ngoài ra, biến thể Circle-STARK đặc biệt thân thiện với Bitcoin do trường số nhỏ.
Do đó, do bộ xác minh Bitcoin có thể tương đối dễ dàng xác minh mọi tính toán, chúng ta có thể chọn loại tính toán nào để xác minh. Đáng chú ý, điều này thậm chí có thể là một loại thực thi CPU nào đó. Hơn nữa, chúng ta có thể thiết kế ngôn ngữ lập trình cấp cao trên nền tảng CPU. Vì mục đích này, tại StarkWare chúng tôi đã phát triển Cairo, một ngôn ngữ lập trình kiểu Rust, thân thiện và an toàn, được thiết kế riêng cho việc chứng minh và xác minh hiệu quả. Chứng minh việc thực thi Cairo trên Bitcoin có thể mang lại lợi thế lớn.
Tổng thể, bằng cách sử dụng bộ xác minh STARK cùng với Covenant, chúng ta có thể đạt được tính toán phổ quát trên Bitcoin. Hơn nữa, loại tính toán này còn có các đặc điểm bổ sung hấp dẫn sau:
-
Mở rộng quy mô — xử lý giao dịch và tính toán trên chuỗi trở nên khả thi với phí cực thấp.
-
Khả năng biểu đạt — logic có thể được lập trình bằng các ngôn ngữ khác mạnh hơn tập lệnh Bitcoin. Điều này rất quan trọng đối với tính thân thiện và an toàn trong lập trình Bitcoin.
-
An toàn trên chuỗi — bất kể tính toán nào, tập lệnh Bitcoin chỉ xác minh bằng chứng toán học về tính toán được ủy quyền.
-
Tính linh hoạt — tính toán trên Bitcoin có thể lưu trữ trạng thái toàn cục, cho phép triển khai nhiều ứng dụng.
7. Sử dụng OP_CAT để nối và các chức năng khác
Như đã nêu, OP_CAT là một mã vận hành đơn giản hiện đang bị vô hiệu hóa, cho phép tập lệnh Bitcoin nối các phần tử trên ngăn xếp. Tầm quan trọng của thao tác đơn giản này không thể bị đánh giá thấp, vì nó có thể đồng thời cho phép Covenant và STARK trên Bitcoin. Cách thực hiện cụ thể như sau:
-
STARK — thực tế, điều này không ngạc nhiên. Bởi vì STARK thực chất chỉ là nối dữ liệu lại với nhau rồi thực hiện băm, do băm là phép tính gốc trong tập lệnh Bitcoin, khác với thao tác đại số, do đó tiết kiệm chi phí đáng kể. Các phép tính băm chính trong STARK là xác minh đường dẫn Merkle (xem Hình 8) và biến đổi Fiat-Shamir. (Hơn nữa, biến thể Circle-STARK có kích thước trường chỉ 31 byte, phù hợp với giới hạn 4 byte của tập lệnh Bitcoin, khiến nó trở thành thuật toán thân thiện với Bitcoin).
-
Covenant — Năm 2021, Andrew Poelstra đã đưa ra một quan sát phi thường rằng OP_CAT có thể thực hiện Covenant trên Bitcoin thông qua cái gọi là mẹo Schnorr, trong đó thuật toán Schnorr là chữ ký số cho loại đầu ra Pay2Taproot (đối với các loại đầu ra khác, có thể sử dụng quan sát của Robin Linus về mẹo ECDSA tương tự). Tóm lại, để thực hiện Covenant, chúng ta cần sử dụng OP_CHECKSIG, mã vận hành duy nhất có thể đưa dữ liệu liên quan đến giao dịch người chi tiêu vào ngăn xếp. Quá trình này không đơn giản, nhưng thông qua một số thao tác, bạn có thể truy cập tất cả dữ liệu cần thiết.
Về điểm cuối cùng, việc lưu trạng thái trong đầu ra Pay2Taproot liên quan đến một số vấn đề kỹ thuật. Tuy nhiên, có thể sử dụng các loại đầu ra khác để lưu trạng thái, như Pay2WitnessScriptHash. Điều này tạo ra kỹ thuật "state caboose" đã đề cập ở Hình 4 và Hình 5, với hai đầu ra trong giao dịch.
Hình 8: *Xác minh đường dẫn Merkle, liên quan đến thao tác nối và băm chuỗi. Các phần của đường dẫn Merkle (chuỗi màu xanh lam) được nối lại và xử lý băm tương ứng. Sau đó, kiểm tra tính bằng nhau với gốc Merkle. OP_CAT được viết thành ||.*
8. Hiện trạng và tương lai
Trong một dự án mã nguồn mở do Weikeng Chen và Pinghzou Yuan lãnh đạo, chúng tôi đang cùng nhau nỗ lực xây dựng Khu Bảo Tồn Thiên Nhiên Bitcoin. Hai dự án chính bao gồm:
-
Bộ xác minh Circle-STARK, bản demo hoạt động có thể xác minh bằng chứng STARK cho một mệnh đề đơn giản (liên quan đến số Fibonacci) trên ký hiệu Bitcoin. Bạn có thể theo dõi tiến độ tại địa chỉ này.
-
Khung Covenant, đã được áp dụng thông qua một Covenant đếm đơn giản. Bộ xác minh cũng sử dụng khung này.
Thông qua nỗ lực này, mục tiêu của chúng tôi là mang đến các hợp đồng thông minh OP_CAT hiệu quả, an toàn và thân thiện với nhà phát triển cho Bitcoin. Chúng tôi cho rằng đây là một viễn cảnh đầy hứa hẹn và thú vị đối với lĩnh vực tính toán Bitcoin.
9. Kết luận
Tổng thể, qua bài viết này, chúng ta hiểu rằng:
-
Covenant là một công cụ mạnh mẽ trong tập lệnh Bitcoin, cho phép tạo hợp đồng thông minh trên Bitcoin. Covenant mở rộng chức năng Bitcoin vượt xa việc chuyển giá trị đơn giản.
-
Tuy nhiên, ngay cả với Covenant, tập lệnh Bitcoin vẫn còn nhiều hạn chế, bao gồm giới hạn kích thước ngăn xếp và loại mã vận hành có thể sử dụng. Điều này hạn chế độ phức tạp và khả năng biểu đạt của hợp đồng thông minh chỉ dùng Covenant.
-
STARK có thể xác minh hiệu quả việc thực thi tính toán ngoài chuỗi, do đó cung cấp một giải pháp đầy hứa hẹn để giảm nhẹ các hạn chế này. Nhờ tận dụng STARK, có thể thực hiện các tính toán phức tạp hơn trong hợp đồng thông minh Bitcoin và tối thiểu hóa mức chiếm dụng tính toán trên chuỗi.
-
Cairo là một ngôn ngữ lập trình được thiết kế riêng để chứng minh và xác minh hiệu quả bằng STARK, rất phù hợp cho hợp đồng thông minh Bitcoin. Nó cho phép tạo các hợp đồng thông minh phức tạp hơn, nâng cao tính thân thiện, chức năng và an toàn.
-
OP_CAT là một mã vận hành tập lệnh Bitcoin dùng để nối các phần tử. OP_CAT đóng vai trò then chốt trong việc thực hiện Covenant và STARK trên Bitcoin, từ đó mang lại khả năng tính toán phổ quát mạnh mẽ cho Bitcoin.
Trong bài viết tiếp theo, chúng ta sẽ đi sâu vào bộ xác minh Circle-STARK trên Bitcoin.
Cảm ơn Weikeng Chen, Pingzhou Yuan và đội ngũ StarkWare đã góp ý quý báu cho bài viết này.
Victor Kolobov
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
@StarkWareLtd
