Mặc dù phạm vi đề xuất khá rộng, nhưng điều gì có thể là lý do khiến "Great Script Recovery" của Rusty Russell được coi là con đường phía trước của sự phát triển Bitcoin?

Ghi chú về kỳ lân khối: Rusty Russell là một nhà phát triển năng động trong cộng đồng Bitcoin và được rất ngưỡng mộ bên trong. Anh đã có những đóng góp đáng kể cho việc phát triển nhân Linux và đã tham gia vào các dự án phát triển Bitcoin Core khác nhau.

Khi Bitcoin được thiết kế ban đầu, nó bao gồm một ngôn ngữ kịch bản hoàn chỉnh nhằm mục đích bao quát và hỗ trợ bất kỳ trường hợp sử dụng bảo mật tiềm năng nào người dùng có thể đề xuất trong tương lai. Như Satoshi Nakamoto đã nói trước khi biến mất:

"Bản chất của Bitcoin là một khi phiên bản 0.1 được phát hành, thiết kế cốt lõi đã được thiết lập trong suốt quãng đời còn lại của nó. Do đó, tôi muốn thiết kế nó để hỗ trợ mọi loại giao dịch mà tôi có thể nghĩ đến, nhưng trong các phiên bản sau, chúng tôi đã loại bỏ khả năng chạy các tập lệnh tùy ý. Vấn đề là mọi tính năng đều yêu cầu mã hỗ trợ đặc biệt và trường dữ liệu, cho dù chúng có được sử dụng hay không, dẫn đến quá nhiều trường hợp đặc biệt. Giải pháp là kịch bản, khái quát hóa vấn đề để các giao dịch có thể mô tả các điều kiện của chúng theo cách cụ thể cho chúng và các nút mạng có thể đánh giá và xác nhận các điều kiện này." - Satoshi Nakamoto, ngày 17 tháng 6 năm 2010

Mục đích chung là cung cấp cho người dùng một ngôn ngữ chung đủ linh hoạt để họ có thể tổ chức các loại giao dịch theo ý muốn của họ. Nói cách khác, nó cung cấp cho người dùng không gian để thiết kế và thử nghiệm cách họ viết tiền của mình.

Trước khi biến mất, Satoshi Nakamoto đã loại bỏ 15 opcode, vô hiệu hóa chúng hoàn toàn, và thêm một giới hạn cứng về kích thước các khối dữ liệu có thể hoạt động trên ngăn xếp script engine (520 byte). Điều này là do anh ấy đã thực sự làm lộn, để lại nhiều cách mà các script phức tạp có thể tiềm ẩn để tiến hành tấn công DOS trên toàn bộ mạng (gửi số lượng lớn các yêu cầu rác, gây tê liệt mạng), tạo ra các giao dịch lớn và đắt đỏ có thể làm đổ bộ địa phương.

Những opcode này không được loại bỏ vì Satoshi Nakamoto coi những chức năng này là nguy hiểm, hoặc là người ta không nên lợi dụng chúng để xây dựng những gì họ có thể, mà chỉ đơn giản (ít nhất là ở mặt bề ngoài) vì chúng đặt một rủi ro cho toàn bộ mạng mà không có giới hạn tài nguyên, và do đó có thể gây ra những chi phí xác minh tồi tệ nhất cho mạng mà không có sự hạn chế nào.

Kể từ đó, mỗi cập nhật Bitcoin cuối cùng đều là việc tối ưu hóa các tính năng còn lại, sửa các lỗi ít nghiêm trọng khác mà Satoshi Nakamoto để lại cho chúng ta, và mở rộng tính năng của tập hợp các kịch bản mà chúng tôi còn lại.

Phục hồi tuyệt vời kịch bản

Tại hội nghị Bitcoin++ tại Austin vào đầu tháng 5, nhà phát triển Lightning Network Rusty Russell đã đưa ra một đề xuất rất triệt để trong bài nói đầu tiên của mình tại hội nghị, nơi ông gần như đề xuất kích hoạt lại hầu hết các mã opcode bị vô hiệu hóa bởi Satoshi Nakamoto trước khi ông biến mất vào năm 2010.

Kể từ khi kích hoạt Taproot vào năm 2021 (Taproot là một bản nâng cấp đáng kể cho Bitcoin nhằm mục tiêu cải thiện sự riêng tư, an ninh và khả năng mở rộng), lĩnh vực phát triển đã trở nên mơ hồ một chút. Hiểu rõ rằng Bitcoin thiếu khả năng mở rộng đủ để thực sự cung cấp dịch vụ độc lập cho bất kỳ dân số đáng kể nào trên thế giới, hoặc thậm chí cung cấp khả năng mở rộng một cách đáng tin cậy hoặc giam cầm ít nhất mà có thể vượt qua các tổ chức giam cầm lớn và các nhà cung cấp dịch vụ, và không thể thực sự thoát khỏi sự giám sát của chính phủ.

Bài viết này nhấn mạnh về một sự hiểu biết ở mức kỹ thuật về Bitcoin, điều đó không phải là một vấn đề để tranh luận. Vấn đề có thể tranh cãi là làm thế nào để giải quyết sự thiếu hụt này, đó là một chủ đề rất gây tranh cãi. Kể từ khi đề xuất Taproot, mọi người đã đưa ra những đề xuất rất hẹp hòi nhắm vào việc giải quyết các vấn đề chỉ có thể đạt được với các trường hợp sử dụng cụ thể.

Ví dụ: ANYPREVOUT (APO) là một đề xuất cho phép chữ ký được sử dụng lại trên các giao dịch khác nhau miễn là các tập lệnh đầu vào và số tiền giống nhau. Đề xuất này được thiết kế đặc biệt để tối ưu hóa Lightning Network và các phiên bản đa bên của nó. CHECKTEMPLATEVERIFY (CTV) là một đề xuất yêu cầu tiền chỉ được chi tiêu bởi các giao dịch khớp chính xác với các giao dịch được xác định trước. Đề xuất này được thiết kế để mở rộng chức năng của các chuỗi giao dịch được ký trước bằng cách làm cho chúng hoàn toàn không đáng tin cậy. OP_VAULT được thiết kế đặc biệt để thiết lập "thời gian chờ" cho các giải pháp lưu trữ lạnh để người dùng có thể "hủy" rút tiền từ kho lạnh bằng cách gửi chúng đến các thiết lập đa chữ ký lạnh hơn để ngăn khóa của họ bị rò rỉ.

Có nhiều đề xuất khác nhau, nhưng tôi nghĩ rằng bạn đã hiểu các điểm chính. Trong những năm gần đây, mỗi đề xuất đã nhắm đến việc tăng khả năng mở rộng một cách nhẹ nhàng hoặc cải thiện một tính năng nhỏ đơn lẻ, vì điều này được coi là mong muốn. Đây là lý do tại sao những cuộc thảo luận này không tiến triển. Không ai hài lòng với các đề xuất khác vì chúng không đáp ứng các trường hợp sử dụng mà họ muốn thấy.

Ngoài những người đề xuất, không ai tin rằng bất kỳ đề xuất nào đủ toàn diện để được coi là bước tiếp theo hợp lý.

Đây là logic đằng sau việc “Khôi phục Kịch bản Tuyệt vời.” Bằng việc ủng hộ và phân tích việc khôi phục toàn diện các kịch bản, đúng như Satoshi Nakamoto đã thiết kế ban đầu, chúng ta có thể thực sự cố gắng khám phá toàn bộ không gian chức năng mà chúng ta cần, thay vì tranh luận và cãi nhau về việc nào là tiện ích mở rộng nhỏ đủ tốt cho lúc này.

Mã OPCODE (Operation Codes)

• OP_CAT: Lấy hai dữ liệu từ ngăn xếp và cộng chúng để tạo thành một dữ liệu.
• OP_SUBSTR: Chấp nhận một tham số độ dài (theo byte), lấy một phần dữ liệu từ ngăn xếp, loại bỏ byte của độ dài đó và đặt chúng trở lại trên ngăn xếp.
• OP_LEFT và OP_RIGHT: Chấp nhận một tham số độ dài, lấy một mảng dữ liệu từ ngăn xếp và loại bỏ byte theo độ dài đã chỉ định từ một bên hoặc bên kia của nó.
• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT và OP_DOWNSHIFT: Chấp nhận một phần tử dữ liệu và thực hiện phép toán bit tương ứng trên nó.
• OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, và OP_MOD: Các toán tử toán học cho phép nhân, chia và phép chia lấy dư (trả về phần dư của phép chia).

Ngoài các mã opcode được liệt kê ở trên để khôi phục, Rusty Russell đề xuất ba mã opcode bổ sung nhằm đơn giản hóa việc kết hợp các mã opcode khác nhau:

OP_CTV (hoặc TXHASH/mã opcode tương đương): Cho phép thi hành cụ thể các phần của một giao dịch, yêu cầu những phần đó phải chính xác những nội dung đã được xác định trước.

CSFS: Cho phép xác minh chữ ký, không chỉ toàn bộ giao dịch, để những phần cụ thể của kịch bản hoặc dữ liệu được sử dụng phải được ký trước khi chúng có thể được thực thi.

OP_TWEAKVERIFY: Một xác nhận hoạt động dựa trên Schnorr, liên quan đến các khóa công khai, chẳng hạn như thêm hoặc trừ các khóa công khai cá nhân khỏi một khóa công khai tổng hợp. Điều này có thể được sử dụng để đảm bảo rằng khi một bên chi tiêu một cách đơn phương từ một đầu ra giao dịch chưa sử dụng (UTXO) chung, các quỹ từ tất cả các bên khác được gửi đến một khóa công khai tổng hợp cho phép chi tiêu hợp tác mà không cần chữ ký của bên rời khỏi UTXO chung.

Tại sao chúng tôi lại làm điều đó?

Mạng lớp 2 về cơ bản là sự mở rộng của lớp cơ sở Bitcoin, và chúng bị ràng buộc bởi các chức năng của lớp cơ sở. Trước khi Mạng Lightning có thể được triển khai, cần ba sự phân nhánh mềm riêng biệt: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) và Segregated Witness (SegWit).

Mà không có một lớp cơ sở linh hoạt hơn, thì không thể xây dựng được các mạng Layer2 linh hoạt hơn. Lối tắt duy nhất là tin tưởng vào bên thứ ba, điều này rất rõ ràng, nhưng tôi hy vọng chúng ta đều khao khát loại bỏ sự tin tưởng vào bên thứ ba càng nhiều càng tốt từ mọi khía cạnh trong việc tương tác với khả năng mở rộng của Bitcoin.

Chúng ta cần có khả năng thực hiện những điều hiện tại là không thể, như việc an toàn hợp nhất hai hoặc nhiều cá nhân vào một đầu ra giao dịch chưa sử dụng (UTXO) và có thể thực thi mà không cần tin cậy trên lớp cơ sở. Độ linh hoạt hiện tại của các script Bitcoin không đủ. Ở mức cơ bản nhất, chúng ta cần các hợp đồng, và chúng ta cần các script để thực sự thực thi các chi tiết cụ thể về việc thực hiện giao dịch để đảm bảo rằng một người dùng thoát khỏi UTXO của họ một cách an toàn không đặt quỹ của người dùng khác vào rủi ro.

Từ một góc độ cao hơn, đây là chức năng chúng ta cần:

Tự quán sát: Chúng tôi cần có khả năng kiểm tra cụ thể về giao dịch chi tiêu trên ngăn xếp, chẳng hạn như “một phần của số tiền này sẽ chuyển đến một khóa công khai cụ thể của một đầu ra.” Điều này cho phép tôi sử dụng nhánh Taproot cụ thể của mình để rút tiền một cách độc lập trong khi đảm bảo rằng tôi không thể lấy tiền của người khác. Kịch bản được thực hiện sẽ đảm bảo rằng các quỹ của các chủ sở hữu khác được gửi trở lại các địa chỉ được tạo ra từ các khóa công khai của người dùng khác để ngăn chặn mất quỹ do các bên tham gia khác.

Chuyển tiếp dữ liệu: Giả sử chúng tôi tiếp tục phát triển khái niệm về một UTXO duy nhất với số lượng lớn người, nơi bất kỳ ai cũng có thể tự do ra vào. Trong trường hợp này, chúng ta cần một cách để theo dõi ai có bao nhiêu tiền, thường sử dụng cây Merkle và rễ của chúng. Điều này có nghĩa là khi ai đó thoát ra, chúng tôi phải đảm bảo rằng "hồ sơ" ai có quyền nhận những gì như một phần của UTXO thay đổi quỹ của người khác. Đây thực chất là một cách sử dụng cụ thể của nội tâm.

Chỉnh sửa Khóa Công khai: Chúng ta cần đảm bảo rằng việc chỉnh sửa các khóa công khai đã được tổng hợp có thể được xác minh trên ngăn xếp. Trong một kế hoạch đầu ra giao dịch không tiêu tốn (UTXO) được chia sẻ, mục tiêu của chúng tôi là tạo điều kiện cho sự hợp tác và luồng quỹ hiệu quả thông qua một khóa công khai đã được tổng hợp chứa tất cả các bên tham gia. Khi một người nào đó rời khỏi UTXO đã được chia sẻ một cách đơn phương, chúng ta cần loại bỏ khóa công khai cá nhân của họ khỏi khóa công khai đã được tổng hợp. Nếu tất cả các kết hợp có thể không được tính toán trước, thì tùy chọn duy nhất là để xác minh xem việc trừ đi một khóa công khai từ khóa công khai đã được tổng hợp có thể tạo ra một khóa công khai hợp lệ được tạo thành từ các khóa công khai cá nhân còn lại.

Đảm bảo bảo mật: Như tôi đã đề cập ở trên, lý do vô hiệu hóa tất cả các mã opcode này là để đối phó với các cuộc tấn công DOS (gây ra sự cố mạng bằng cách gửi một lượng lớn yêu cầu rác), có thể dẫn đến sự cố của các nút tạo thành mạng. Một cách để giải quyết vấn đề này là bằng cách giới hạn số lượng tài nguyên mà bất kỳ mã opcode nào trong số đó có thể sử dụng.

Khi nói đến xác minh chữ ký, phần đắt nhất của tập lệnh Bitcoin, chúng tôi đã có một giải pháp cho việc này được gọi là ngân sách Hoạt động chữ ký (sigops). Mỗi lần sử dụng opcode kiểm tra chữ ký tiêu tốn một "ngân sách" nhất định, tức là số lượng hoạt động chữ ký được phép trên mỗi khối, đặt giới hạn cứng về chi phí cần thiết để xác thực khối cho giao dịch cho người dùng. Taproot thay đổi cách thức hoạt động bằng cách không còn sử dụng một giới hạn khối toàn cầu duy nhất, nhưng mỗi giao dịch có giới hạn sigops (hoạt động chữ ký) riêng, tỷ lệ thuận với kích thước của giao dịch. Điều này về cơ bản bằng cùng một giới hạn toàn cầu nhưng giúp dễ hiểu hơn về số lượng sigop mà mỗi giao dịch có sẵn.

Sự thay đổi trong Taproot liên quan đến giới hạn sigops (hoạt động chữ ký) cho mỗi giao dịch cung cấp khả năng tiếp cận tổng quát, đây cũng là đề xuất mà Rusty Russell đề xuất liên quan đến các hạn chế của varops. Ý tưởng là phân bổ chi phí cho mỗi opcode được kích hoạt lại để tính đến trường hợp xấu nhất mà mỗi opcode có thể tạo ra về chi phí tính toán đắt nhất trong quá trình xác minh. Do đó, mỗi opcode sẽ có giới hạn "sigops" riêng, giới hạn lượng tài nguyên mà nó có thể tiêu thụ trong quá trình xác minh. Điều này cũng sẽ dựa trên kích thước của bất kỳ giao dịch nào sử dụng các opcode này, thuận tiện cho việc suy luận trong khi vẫn tích lũy đến giới hạn toàn cầu ngầm của mỗi khối. Điều này sẽ giải quyết các cuộc tấn công DOS (gây ra sự cố mạng bằng cách gửi một lượng lớn yêu cầu rác), đó cũng là lý do Satoshi Nakamoto ban đầu vô hiệu hóa tất cả các opcode này.

Sức mạnh đẩy mạnh

Tôi tin rằng nhiều người trong số bạn có thể nghĩ, “Đó là một thay đổi lớn.” Tôi hiểu quan điểm này, nhưng tôi nghĩ một khía cạnh quan trọng để hiểu về một đề xuất là chúng ta không cần phải thực hiện tất cả mọi thứ ngay lập tức. Giá trị của đề xuất này có thể không nhất thiết nằm ở việc khôi phục hoàn toàn tất cả các chức năng này, mà là ở việc chúng ta cần xem xét kỹ lưỡng một bộ sưu tập rộng lớn các thành phần nền tảng và tự đặt câu hỏi về những chức năng mà chúng ta thực sự mong muốn.

Điều này sẽ đánh dấu một sự thay đổi hoàn toàn so với ba năm qua của việc tranh luận và cãi nhau, nơi chúng tôi chỉ đơn giản là tranh luận về những thay đổi nhỏ, hẹp, những thay đổi chỉ ảnh hưởng đến một số chức năng cụ thể. Đó giống như một hình vuông nơi mà mọi người có thể tụ tập và cùng nhau suy nghĩ về hướng đi của tương lai. Có lẽ, cuối cùng, chúng tôi sẽ khôi phục lại tất cả những chức năng này, hoặc có thể chúng tôi sẽ chỉ kích hoạt một số, vì sự đồng thuận đến từ việc đồng ý về những chức năng mà chúng tôi tin rằng cần được kích hoạt.

Dù kết quả cuối cùng như thế nào, điều này có thể là một thay đổi tích cực ảnh hưởng đến toàn bộ cuộc đối thoại về hướng đi của tương lai của chúng ta. Chúng ta thực sự có thể đặt ra và hiểu rõ tình hình, thay vì vấp phải khi tranh luận về bước tiếp theo trên một con đường mập mờ.

Điều này hoàn toàn không phải là cách duy nhất mà chúng ta phải theo đuổi, nhưng tôi tin rằng nó mang lại cơ hội tốt nhất cho chúng ta quyết định con đường nào để đi. Đã đến lúc bắt đầu làm việc cùng nhau một lần nữa một cách thực tế và hiệu quả.

Tuyên bố:

1. Bài viết này ban đầu có tựa đề “伟大的脚本恢复：比特币的前进之路” được sao chép từ [ Khối kỳ lân]. Tất cả bản quyền thuộc về tác giả gốc [SHINOBI]. Nếu bạn có bất kỳ ý kiến phản đối nào về việc tái in, vui lòng liên hệ với Cổng Họcđội, đội sẽ xử lý nó càng sớm càng tốt.

2. Bản quyền: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ đại diện cho quan điểm cá nhân của tác giả và không cấu thành 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.