Bitcoin ban đầu được thiết kế với một ngôn ngữ kịch bản hoàn chỉnh, nhằm bao gồm và hỗ trợ bất kỳ trường hợp sử dụng an toàn tiềm năng nào mà người dùng có thể đưa ra trong tương lai. Như chính Satoshi đã 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 có thể mà tôi có thể nghĩ ra. Vấn đề là, mỗi thứ đều yêu cầu mã hỗ trợ đặc biệt và các trường dữ liệu cho dù nó có được sử dụng hay không và chỉ bao gồm một trường hợp đặc biệt tại một thời điểm. Đó sẽ là một sự bùng nổ của các 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 bên giao dịch có thể mô tả giao dịch của họ như một vị ngữ mà mạng nút đánh giá." - Satoshi, ngày 17 tháng 6 năm 2010.

Toàn bộ mục đích là cung cấp cho người dùng một ngôn ngữ đủ chung để họ có thể soạn các loại giao dịch của riêng mình khi họ thấy phù hợp. Tức là Cung cấp cho người dùng không gian để thiết kế và thử nghiệm cách họ lập trình tiền của chính họ.

Trước khi biến mất, Satoshi đã tách ra 15 opcode này, vô hiệu hóa chúng hoàn toàn và thêm một giới hạn cứng về mức độ lớn của một phần dữ liệu có thể được thao tác trên ngăn xếp công cụ kịch bản (520 byte). Điều này được thực hiện bởi vì anh ta thẳng thắn làm hỏng và để ngỏ một số lượng lớn các cách mà các tập lệnh phức tạp có thể được sử dụng để từ chối dịch vụ tấn công toàn bộ mạng, tạo ra rất lớn và tốn kém để xác thực các giao dịch sẽ làm sập các nút.

Các opcode này không bị xóa vì Satoshi nghĩ rằng chức năng này nguy hiểm hoặc mọi người không thể xây dựng những thứ họ có thể với chúng, nhưng chỉ (ít nhất là rõ ràng) vì rủi ro đối với mạng nói chung được sử dụng mà không có ràng buộc về tài nguyên để hạn chế chi phí xác thực trường hợp xấu nhất mà họ có thể áp đặt trên mạng.

Mỗi lần nâng cấp lên Bitcoin kể từ đó cuối cùng đã hợp lý hóa chức năng còn lại, sửa chữa các lỗi ít nghiêm trọng khác mà Satoshi để lại cho chúng tôi và mở rộng chức năng của tập hợp con tập lệnh mà chúng tôi còn lại.

THE GREAT SCRIPT RESTORATION

Tại Bitcoin++ ở Austin vào đầu tháng Năm, nhà phát triển Core Lightning Rusty Russell đã đưa ra một đề xuất khá triệt để trong bài thuyết trình đầu tiên của hội nghị. Về cơ bản, anh ấy đã đưa ra ý tưởng quay trở lại hầu hết các mã opcode Satoshi vô hiệu hóa vào năm 2010 trước khi anh ấy biến mất.

Trong vài năm qua kể từ khi Taproot kích hoạt vào năm 2021, không gian phát triển thẳng thắn là không có mục đích. Chúng ta đều biết rằng Bitcoin không đủ khả năng mở rộng để thực sự phục vụ bất kỳ phần lớn dân số thế giới nào theo cách tự chủ, và thậm chí có khả năng không theo cách giảm thiểu hoặc giám sát niềm tin có thể mở rộng ra ngoài những người giám sát và nhà cung cấp dịch vụ rất lớn không có khả năng thực sự thoát khỏi cánh tay long của chính phủ.

Bất cứ ai hiểu Bitcoin ở cấp độ công nghệ đều hiểu điều này, đó không phải là vấn đề tranh luận. Một vấn đề tranh luận, và một vấn đề rất gây tranh cãi, là làm thế nào để giải quyết thiếu sót này. Kể từ năm Taproot, mọi người đã đưa ra các đề xuất rất hẹp nhằm chỉ giải quyết các trường hợp sử dụng rất cụ thể có thể được kích hoạt.

ANYPREVOUT (APO), một đề xuất cho phép chữ ký có thể tái sử dụng trên các giao dịch khác nhau long như tập lệnh và số lượng đầu vào giống nhau đã được điều chỉnh đặc biệt để tối ưu hóa Lightning và các phiên bản đa bên của nó. CHECKTEMPLATEVERIFY (CTV), một đề xuất để thực thi tiền xu chỉ có thể được chi tiêu bởi một giao dịch khớp chính xác với một giao dịch được xác định trước, được thiết kế đặc biệt để mở rộng chức năng của chuỗi các 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 để cho phép "khoảng thời gian chờ" cho các chương trình lưu trữ lạnh, để người dùng có thể "hủy" việc rút tiền từ kho lạnh bằng cách gửi nó đến một thiết lập đa chữ ký thậm chí còn lạnh hơn nếu khóa của họ bị xâm phạm.

Có một loạt các đề xuất khác, nhưng tôi nghĩ bạn hiểu được điểm. Thay vì cố gắng giải quyết toàn diện tính biểu cảm và khả năng lập trình cần thiết để mở rộng quy mô Bitcoin một cách cơ bản, mỗi đề xuất trong vài năm qua được thiết kế để tăng một chút khả năng mở rộng hoặc cải thiện một chức năng hẹp duy nhất được coi là mong muốn. Điều này tôi nghĩ là nguồn gốc của lý do tại sao không có cuộc trò chuyện nào trong số này đi đến đâu. Không ai hài lòng với bất kỳ đề xuất nào khác vì nó không phục vụ cho trường hợp sử dụng mà họ muốn thấy được xây dựng.

Không có gì đủ toàn diện để bất cứ ai nghĩ, ngoài người khởi tạo đề xuất, rằng đó là bước tiếp theo hợp lý.

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

MÃ OPCODE

• OP_CAT: Lấy hai phần dữ liệu trên ngăn xếp và cộng chúng lại với nhau để tạo thành một.
• OP_SUBSTR: Lấy một đối số độ dài tính bằng byte và lấy một phần dữ liệu ra khỏi ngăn xếp loại bỏ nhiều byte khỏi nó và đưa nó trở lại.
• OP_LEFT &OP_RIGHT: Lấy một đối số độ dài và loại bỏ nhiều byte đó từ bên này hay bên kia của một phần dữ liệu trên ngăn xếp.
• OP_INVERT &OP_AND &OP_OR &OP_XOR & OP_UPSHIFT &OP_DOWNSHIFT: Lấy một phần tử dữ liệu từ ngăn xếp và thực hiện thao tác bit tương ứng trên đó.
• OP_2MUL &OP_2DIV &OP_MUL &OP_DIV &OP_MOD: Toán tử cho phép toán, phép chia và phép toán modulo (trả về phần còn lại của phép chia).

Những cái trên là các mã opcode dự định được khôi phục. Ngoài ra, Rusty đề xuất thêm ba để đơn giản hóa thành phần của các opcode khác nhau.

• OP_CTV (HOẶC TXHASH/tương đương): Một cái gì đó để cho phép thực thi chi tiết yêu cầu một số phần nhất định của giao dịch phải chính xác như được xác định trước thời hạn.
• CSFS: Cho phép xác minh chữ ký dựa trên dữ liệu tùy ý, thay vì chỉ toàn bộ giao dịch. Điều này cho phép bạn yêu cầu các phần của tập lệnh hoặc dữ liệu chúng sử dụng phải được đăng nhập lệnh được thực thi.
• OP_TWEAKVERIFY: Xác minh các hoạt động dựa trên Schnorr liên quan đến khóa công khai, chẳng hạn như thêm hoặc trừ các khóa công khai riêng lẻ khỏi các khóa tổng hợp. Điều này có thể được sử dụng để đảm bảo rằng trong trường hợp một bên đơn phương rời khỏi UTXO chia sẻ, tiền của mọi người khác được gửi đến một khóa công khai tổng hợp không yêu cầu bên rời đi đăng nhập lệnh chi tiêu hợp tác.

WHY WE WANT TO DO THIS

Lớp 2 vốn là một phần mở rộng của lớp cơ sở của Bitcoin, bản chất của chúng bị hạn chế về chức năng bởi chức năng của lớp cơ sở. Lightning yêu cầu ba softfork riêng biệt, CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) và Bằng chứng tách biệt trước khi có thể thực sự triển khai nó.

Bạn không thể xây dựng Lớp 2 linh hoạt hơn nếu không có lớp cơ sở linh hoạt hơn. Lối tắt duy nhất xung quanh đó là các bên thứ ba đáng tin cậy, thuần túy và đơn giản. Đó là điều tôi hy vọng tất cả chúng ta đều mong muốn loại bỏ khỏi mọi khía cạnh của việc tương tác với Bitcoin ở quy mô mà chúng ta có thể.

Có những điều chúng ta cần để có thể làm mà chúng ta không thể làm ngay bây giờ trong lệnh để đóng gói an toàn nhiều hơn hai người vào một UTXO duy nhất theo cách có thể được thực thi một cách đáng tin cậy trên lớp cơ sở Bitcoin tập lệnh không đủ linh hoạt. Ở cấp độ cơ bản nhất, chúng ta cần các giao ước, chúng ta cần khả năng tập lệnh thực sự thực thi các chi tiết chi tiết hơn về giao dịch thực hiện chúng để đảm bảo những thứ như người dùng tự thoát khỏi UTXO một cách an toàn không khiến tiền của người dùng khác gặp rủi ro.

Ở chế độ xem cao, đây là loại chức năng chúng ta cần:

Nội quan: Chúng ta cần có khả năng thực sự kiểm tra các chi tiết cụ thể về chính một giao dịch chi tiêu trên ngăn xếp, chẳng hạn như "số tiền này đi vào khóa công khai này trong một số đầu ra." Điều đó cho phép tôi tự rút tiền của mình bằng cách sử dụng một chi nhánh Taproot cụ thể của riêng tôi, đồng thời đảm bảo rằng tôi không thể lấy tiền của bất kỳ ai khác. Việc thực thi tập lệnh sẽ thực thi bằng sự đồng thuận rằng số tiền chính xác mà mọi người khác sở hữu sẽ được gửi trở lại địa chỉ bao gồm các khóa công khai của người dùng khác nếu tôi rời đi.

Chuyển tiếp dữ liệu: Giả sử chúng tôi đi xa hơn ý tưởng về kênh Lightning với nhiều hơn hai người trong đó, chúng tôi xây dựng một UTXO duy nhất với một lượng lớn người trong đó, nơi bất kỳ ai cũng có thể đến và đi khi họ muốn. Bằng cách nào đó, hầu như luôn luôn với một cây merkle và rễ của nó, chúng ta cần một số cách để theo dõi ai có bao nhiêu tiền. Điều đó có nghĩa là khi ai đó rời đi, chúng ta phải có khả năng đảm bảo rằng "hồ sơ" về những người được hưởng những gì là một phần của sự thay đổi UTXO tiền của người khác. Đây thực chất là một cách sử dụng cụ thể để xem xét nội tâm.

Sửa đổi Khóa công khai: Chúng tôi cần khả năng đảm bảo rằng các sửa đổi để tổng hợp khóa công khai có thể được xác minh trên ngăn xếp. Mục tiêu để đạt được trong các chương trình chia sẻ UTXO là có một chìa khóa tổng hợp với tất cả mọi người tham gia cho phép di chuyển các quỹ hợp tác và hiệu quả hơn. Bất cứ khi nào ai đó đơn phương rời khỏi UTXO được chia sẻ, chúng tôi cần xóa khóa cá nhân của họ khỏi khóa tổng hợp. Nếu không tính toán trước tất cả các kết hợp có thể, tùy chọn duy nhất là có thể xác minh rằng việc trừ một khóa khỏi tổng hợp sẽ tạo ra một khóa hợp lệ bao gồm phần còn lại của các khóa riêng lẻ.

LÀM THẾ NÀO ĐỂ LÀM CHO ĐIỀU NÀY AN TOÀN: VAROPS

Như tôi đã nói ở trên, lý do tất cả các opcode này bị vô hiệu hóa là để loại bỏ rủi ro tấn công từ chối dịch vụ có thể làm sập các nút bao gồm mạng theo đúng nghĩa đen. Có một cách để giải quyết vấn đề này, hạn chế lượng tài nguyên mà bất kỳ opcode nào trong số này có thể sử dụng.

Chúng tôi đã có một giải pháp như vậy khi nói đến xác minh chữ ký, phần tốn kém nhất của việc xác minh các tập lệnh Bitcoin. Nó được gọi là ngân sách 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 cho các hoạt động chữ ký được phép trên mỗi khối. Điều này đặt ra một giới hạn cứng về chi phí mà các giao dịch có thể áp đặt cho người dùng để xác minh một khối riêng lẻ.

Taproot đã thay đổi cách thức hoạt động này, thay vì sử dụng một giới hạn khối toàn cầu duy nhất, mỗi giao dịch có giới hạn sigops riêng tỷ lệ thuận với quy mô của giao dịch. Điều này về cơ bản hoạt động với cùng một giới hạn toàn cầu, nhưng làm cho nó dễ dàng hơn để lý luận về số lượng sigops một giao dịch cá nhân có sẵn.

Sự thay đổi trong cách Taproot xử lý các giới hạn sigops liên quan đến mỗi giao dịch cung cấp một cách để khái quát hóa điều này, đó là những gì Rusty đề xuất với giới hạn varops. Ý tưởng là gán chi phí cho mỗi opcode được kích hoạt lại để đưa vào tài khoản trường hợp xấu nhất, tức là chi phí tính toán đắt nhất để xác thực, mà mỗi opcode có thể tạo ra. Với điều này, mỗi một trong những opcode này sẽ có giới hạn "sigops" riêng để hạn chế số lượng tài nguyên mà nó có thể tiêu thụ trong quá trình xác minh. Nó cũng sẽ dựa trên kích thước của bất kỳ giao dịch nào sử dụng chúng, vì vậy hãy duy trì sự dễ dàng lý luận về nó, trong khi vẫn thêm vào giới hạn toàn cầu ngầm cho mỗi khối.

Điều này sẽ giải quyết các rủi ro từ chối dịch vụ khiến Satoshi vô hiệu hóa tất cả các opcode này ngay từ đầu.

ĐỘNG LƯỢNG CHUYỂN TIẾP

Tôi chắc chắn rằng nhiều người trong số các bạn đang nghĩ rằng "đó là một sự thay đổi quá lớn." Tôi có thể đồng cảm với điều đó, nhưng tôi nghĩ một khía cạnh quan trọng của dự án này như một đề xuất để hiểu là chúng ta không phải làm tất cả. Giá trị của đề xuất này không nhất thiết phải thực sự bật lại tất cả những điều này một cách tổng thể, mà thực tế là chúng ta thực sự sẽ xem xét toàn diện một bộ nguyên thủy khổng lồ và tự hỏi mình thực sự muốn gì từ điều này về mặt chức năng.

Nó sẽ là một khuôn mặt hoàn chỉnh từ ba năm cãi nhau và tranh cãi về những thay đổi nhỏ hẹp, hẹp chỉ giúp ích cho một số chức năng nhất định. Đó là một chiếc lều có thể mang mọi người lại với nhau dưới một mái nhà để thực sự đánh giá toàn diện nơi để đi từ đây. Có lẽ chúng tôi sẽ bật lại tất cả những điều này, có thể chúng tôi chỉ kích hoạt một vài thứ vì sự đồng thuận là đó là tất cả những gì chúng tôi cần để kích hoạt chức năng mà mọi người đều đồng ý rằng chúng tôi cần.

Bất kể kết quả cuối cùng thực sự là gì, nó có thể là một thay đổi hiệu quả trong toàn bộ cuộc trò chuyện xung quanh nơi chúng ta đi từ đây. Chúng ta thực sự có thể vạch ra và có được một vùng đất toàn diện, thay vì loay hoay tranh cãi về con đường âm u và nửa sáng để đi xuống tiếp theo.

Điều này không có nghĩa là phải là con đường phía trước mà chúng tôi thực hiện, nhưng tôi nghĩ đó là cách tốt nhất của chúng tôi để quyết định chúng tôi làm gì. Đã đến lúc bắt đầu thực sự làm việc cùng nhau một cách hiệu quả một lần nữa.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [bitcoinmagazine], Tất cả bản quyền thuộc về tác giả gốc [SHINOBI]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn và họ sẽ xử lý kịp thời.
2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Bản dịch 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 đề cập, việc sao chép, phân phối hoặc đạo văn các bài báo đã dịch đều bị cấm.