Tác giả gốc: SHINOBI
Biên soạn gốc: Block Unicorn
Bất chấp phạm vi đề xuất khá rộng, lý do tại sao “Great Script Recovery” của Rusty Russell có thể là con đường phía trước để phát triển Bitcoin?
Block Unicorn Lưu ý: Rusty Russell là một nhà phát triển tích cực trong cộng đồng Bitcoin và rất được tôn trọng trong cộng đồng. Ông đã thực hiện xuất sắc công việc phát triển nhân Linux và cũng đã tham gia vào nhiều dự án phát triển Bitcoin Core.
Bitcoin ban đầu được thiết kế với ngôn ngữ kịch bản hoàn chỉnh nhằm bao quát và hỗ trợ mọi trường hợp sử dụng bảo mật tiềm năng mà người dùng có thể nghĩ ra trong tương lai. Như Satoshi Nakamoto đã nói trước khi biến mất:
“Bản chất của Bitcoin là khi phiên bản 0.1 được phát hành, thiết kế cốt lõi được thiết lập cho phần còn lại của vòng đời. Vì vậy, 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à các trường dữ liệu là bắt buộc, dẫn đến rất nhiều trường hợp đặc biệt cho dù chúng có được sử dụng hay không. Giải pháp là viết kịch bản, khái quát hóa vấn đề để cả hai bên có thể sử dụng các điều kiện cụ thể để mô tả các giao dịch của họ với mạng nút. được đánh giá hoặc xác minh dựa trên những điều kiện này. - Satoshi Nakamoto, ngày 17 tháng 6 năm 2010.
Toàn bộ mục đích của ông là cung cấp cho người dùng một ngôn ngữ đủ tổng quát để cho phép họ tổ chức các loại giao dịch của riêng mình theo ý muốn. Nghĩa là, cung cấp cho người dùng không gian để thiết kế và thử nghiệm cách mã hóa loại tiền tệ của riêng họ.
Trước khi biến mất, Satoshi đã loại bỏ 15 mã trong số này, vô hiệu hóa chúng hoàn toàn và thêm giới hạn cứng vào ngăn xếp công cụ tập lệnh nhằm giới hạn kích thước của các khối dữ liệu có thể được vận hành trên đó (520 byte). Điều này là do anh ta thực sự đã làm sai, để lại rất nhiều cách trong đó các tập lệnh phức tạp có thể được sử dụng để thực hiện một cuộc tấn công DOS trên toàn bộ mạng (gửi nhiều yêu cầu spam, khiến mạng ngừng hoạt động), tạo ra các giao dịch lớn và tốn kém. và sẽ khiến nút bị hỏng.
Các opcode này không bị xóa vì Satoshi Nakamoto cho rằng các tính năng này nguy hiểm hoặc mọi người không thể xây dựng mọi thứ với chúng, mà đơn giản (ít nhất là trên bề mặt) vì chúng được sử dụng mà không bị hạn chế về tài nguyên. toàn bộ mạng, sao cho họ có thể áp đặt chi phí xác minh trong trường hợp xấu nhất trên mạng mà không bị hạn chế.
Kể từ đó, mọi nâng cấp lên Bitcoin đều trở thành tối ưu hóa chức năng của chức năng còn lại, sửa các lỗi khác ít nghiêm trọng hơn mà Satoshi để lại cho chúng tôi và mở rộng chức năng của tập hợp con các tập lệnh còn lại của chúng tôi.
Kịch bản tuyệt vời để phục hồi
Tại hội nghị Bitcoin++ ở Austin vào đầu tháng 5, nhà phát triển cốt lõi của Lightning Network, Rusty Russell đã đưa ra một đề xuất rất cấp tiến trong bài phát biểu đầu tiên của mình tại hội nghị, nơi về cơ bản ông đề xuất kích hoạt lại Satoshi Nakamoto. Ý tưởng là vô hiệu hóa hầu hết các opcode trước khi biến mất vào năm 2010.
Trong những năm kể từ khi kích hoạt Taproot vào năm 2021, một bản nâng cấp lớn của Bitcoin được thiết kế để cải thiện quyền riêng tư, bảo mật và khả năng mở rộng, bối cảnh phát triển có phần không có mục đích. Tất cả chúng ta đều biết rằng Bitcoin không đủ khả năng mở rộng để thực sự phục vụ dân số tự chủ ở bất kỳ quy mô đáng kể nào trên thế giới, thậm chí có thể theo cách giảm thiểu sự tin cậy hoặc quyền giám sát để có thể mở rộng ra ngoài những người giám sát và nhà cung cấp dịch vụ, dịch vụ rất lớn. các nhà cung cấp thực sự không thể thoát khỏi sự kiểm soát lâu dài của chính phủ trong việc cung cấp khả năng mở rộng.
Bài viết này chỉ ra sự hiểu biết kỹ thuật về Bitcoin, đây không phải là vấn đề cần phải tranh luận. Câu hỏi gây tranh cãi là làm thế nào để giải quyết lỗ hổng này, đây là một chủ đề gây nhiều tranh cãi. Kể từ khi Taproot được giới thiệu, mọi người đều đưa ra những đề xuất rất hẹp nhằm giải quyết các vấn đề chỉ có thể thực hiện được trong những trường hợp sử dụng cụ thể.
Ví dụ: ANYPREVOUT (APO) là một đề xuất cho phép sử dụng lại chữ ký trong các giao dịch khác nhau miễn là tập lệnh đầu vào và số lượng giống nhau. Đề xuất này được thiết kế đặc biệt để tối ưu hóa Lightning Network và phiên bản nhiều bên của nó. CHECKTEMPLATEVERIFY (CTV) là một đề xuất yêu cầu chỉ sử dụng tiền xu cho các giao dịch khớp chính xác với 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 chuỗi giao dịch được ký trước bằng cách làm cho chúng hoàn toàn không cần tin cậy. OP_VAULT được thiết kế đặc biệt để đặt khoảng thời gian hết thời gian cho các chương trình lưu trữ lạnh để người dùng có thể hủy các trích xuất từ kho lạnh bằng cách gửi chúng đến thiết lập đa chữ ký lạnh hơn để ngăn chặn việc khóa của họ bị xâm phạm.
Có nhiều đề xuất khác, nhưng tôi nghĩ bạn đã nắm được ý chính. Mọi đề xuất trong vài năm qua đều nhằm mục đích tăng nhẹ khả năng mở rộng hoặc cải thiện một tính năng nhỏ duy nhất vì điều đó được coi là mong muốn. Đây chính là nguyên nhân khiến 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ác trường hợp sử dụng mà họ muốn thấy.
Không ai khác ngoài người tài trợ đề xuất tin rằng bất kỳ đề xuất nào cũng đủ toàn diện để được coi là bước tiếp theo hợp lý.
Đây là logic đằng sau Great Script Recovery. Bằng cách thúc đẩy và phân tích quá trình khôi phục hoàn toàn tập lệnh, như Satoshi thiết kế ban đầu, chúng tôi thực sự có thể cố gắng khám phá toàn bộ không gian tính năng mà chúng tôi cần, thay vì tranh cãi và đấu tranh nội bộ về việc tiện ích mở rộng tính năng nhỏ nào đủ tốt ngay bây giờ.
OPCODES (Mã hoạt động)
OP_CAT: Lấy hai dữ liệu từ ngăn xếp và thêm chúng để tạo thành một dữ liệu.
OP_SUBSTR: Chấp nhận tham số độ dài (tính bằng byte), lấy một phần dữ liệu từ ngăn xếp, xóa byte có độ dài đó và đặt chúng trở lại ngăn xếp.
OP_LEFT và OP_RIGHT: Chấp nhận tham số độ dài, lấy một phần dữ liệu từ ngăn xếp và xóa các byte có độ dài được chỉ định khỏi một bên 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 thao tác bit tương ứng trên nó.
OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV và OP_MOD: Các toán tử toán học cho phép nhân, chia và modulo (trả về phần dư của phép chia).
Ngoài các opcode được liệt kê ở trên để khôi phục, Rusty Russell còn đề xuất ba opcode bổ sung được thiết kế để đơn giản hóa việc kết hợp các opcode khác nhau:
OP_CTV (hoặc TXHASH/opcode tương đương): Cho phép thực thi chi tiết các phần nhất định của giao dịch, yêu cầu các phần đó phải nhất quán chính xác với 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, do đó các phần nhất định của tập lệnh 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: Xác minh các hoạt động dựa trên Schnorr liên quan đến khóa chung, chẳng hạn như thêm hoặc bớt một khóa chung khỏi khóa chung tổng hợp. Điều này có thể được sử dụng để đảm bảo rằng khi một bên đơn phương rời khỏi đầu ra giao dịch chưa chi tiêu được chia sẻ (UTXO), tất cả tiền của các bên khác sẽ được gửi đến một tổ chức công khai mà không yêu cầu chữ ký của bên còn lại để hợp tác chi tiêu.
Tại sao chúng ta làm việc này
Mạng lớp 2 về cơ bản là phần mở rộng của lớp cơ sở Bitcoin và chúng bị hạn chế về mặt chức năng bởi khả năng của lớp cơ sở. Lightning Network yêu cầu ba nhánh mềm riêng biệt trước khi có thể triển khai thực sự: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) và Segregated Witness.
Bạn không thể xây dựng mạng Lớp 2 linh hoạt hơn nếu không có lớp cơ sở linh hoạt hơn. Con đường tắt duy nhất là tin tưởng vào bên thứ ba, điều đó khá đơn giản và hiển nhiên và tôi hy vọng tất cả chúng ta đều mong muốn loại bỏ lòng tin từ bên thứ ba càng nhiều càng tốt khỏi mọi khía cạnh tương tác với Bitcoin trên quy mô lớn.
Chúng tôi cần có khả năng thực hiện điều mà hiện tại không thể hợp nhất một cách an toàn nhiều hơn hai thành một Đầu ra giao dịch chưa chi tiêu (UTXO) duy nhất và có thể thực hiện điều đó một cách an toàn trên lớp cơ sở. Bitcoin Script hiện chưa đủ linh hoạt. Ở cấp độ cơ bản nhất, chúng tôi cần các hợp đồng, chúng tôi cần các tập lệnh thực sự có thể thực thi các chi tiết tốt hơn về việc thực hiện giao dịch để đảm bảo rằng một người dùng có thể thoát khỏi UTXO của riêng họ một cách an toàn mà không gây rủi ro cho tiền của người dùng khác.
Ở mức độ cao, đây là chức năng chúng ta cần:
Xem xét nội tâm: Chúng ta cần có khả năng thực sự kiểm tra các chi tiết cụ thể trên ngăn xếp về bản thân giao dịch chi tiêu, chẳng hạn như số tiền này sẽ được chuyển đến khóa công khai của một đầu ra nhất định. Điều này cho phép tôi tự rút tiền bằng cách sử dụng chi nhánh Taproot cụ thể của riêng mình đồng thời đảm bảo rằng tôi không thể rút tiền của bất kỳ ai khác. Tập lệnh được thực thi sẽ đảm bảo rằng tiền của các chủ sở hữu khác được gửi trở lại địa chỉ bao gồm khóa chung của người dùng khác, ngăn chặn việc những người tham gia khác bị mất tiền.
Chuyển tiếp dữ liệu: Giả sử chúng ta phát triển hơn nữa khái niệm về một UTXO duy nhất với số lượng lớn người và bất kỳ ai cũng có thể vào và ra theo ý muốn. Trong trường hợp này, chúng ta cần một cách để theo dõi xem ai có bao nhiêu tiền, thường sử dụng cây Merkle và rễ của nó. Điều này có nghĩa là khi ai đó rời đi, chúng tôi phải đảm bảo ghi lại ai được hưởng những gì như một phần của sự thay đổi UTXO trong quỹ của những người khác. Về cơ bản, đây là một cách sử dụng cụ thể của sự xem xét nội tâm.
Sửa đổi khóa công khai: Chúng tôi cần đảm bảo rằng các sửa đổi đối với khóa chung tổng hợp có thể được xác minh trên ngăn xếp. Trong kế hoạch chia sẻ Đầu ra giao dịch chưa chi tiêu (UTXO), mục tiêu của chúng tôi là thúc đẩy hợp tác và dòng tiền hiệu quả thông qua khóa công khai tổng hợp bao gồm tất cả những người tham gia. Khi ai đó đơn phương rời khỏi UTXO được chia sẻ, chúng tôi cần xóa khóa chung cá nhân của họ khỏi khóa chung 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 rằng việc trừ một khóa chung khỏi khóa chung tổng hợp sẽ tạo ra khóa chung hợp lệ bao gồm các khóa chung riêng lẻ còn lại.
Cách giữ an toàn: VAROPS Như tôi đã nói ở trên, lý do vô hiệu hóa tất cả các opcode này là để giải quyết các cuộc tấn công DOS (khiến mạng gặp sự cố do gửi nhiều yêu cầu rác) có thể khiến các nút tạo nên mạng gặp sự cố. Một cách để giải quyết vấn đề này là giới hạn số lượng tài nguyên mà bất kỳ mã hoạt động nào trong số này 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ó giải pháp cho vấn đề này và nó được gọi là lập ngân sách cho Hoạt động Chữ ký (sigops). Mỗi lần sử dụng opcode kiểm tra chữ ký sẽ tiêu tốn một ngân sách nhất định, đó là số lượng thao tác chữ ký được phép trên mỗi khối, đặt ra giới hạn cứng về chi phí mà một giao dịch có thể phải chịu đối với người dùng để xác minh một khối.
Taproot thay đổi cách thức hoạt động, 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 (hoạt động chữ ký) riêng, tỷ lệ thuận với quy mô của giao dịch. Về cơ bản, điều này tương đương với 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 sigops có sẵn cho mỗi giao dịch.
Những thay đổi của Taproot về cách xử lý giới hạn sigops (hoạt động chữ ký) của mỗi giao dịch mở ra khả năng áp dụng một cách tiếp cận tổng quát hóa, điều này cũng được Rusty Russell đề xuất về giới hạn varops. Ý tưởng là ấn định 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, tức là chi phí tính toán đắt nhất phát sinh khi xác thực. Bằng cách này, mỗi opcode sẽ có giới hạn sigops riêng, giới hạn lượng tài nguyên có thể tiêu thụ trong quá trình xác minh. Điều này cũng sẽ dựa trên quy mô của bất kỳ giao dịch nào sử dụng các mã hoạt động này, do đó, việc suy luận có thể được tạo điều kiện thuận lợi trong khi vẫn tích lũy giới hạn toàn cầu ngầm định cho mỗi khối.
Điều này sẽ giải quyết các cuộc tấn công DOS (khiến mạng gặp sự cố do gửi quá nhiều yêu cầu spam) do các giao dịch spam này, đây là nguyên nhân khiến Satoshi vô hiệu hóa tất cả các opcode này ngay từ đầu.
Động lực chuyển tiếp
Tôi chắc rằng nhiều bạn đang nghĩ điều này thay đổi quá nhiều. Tôi có thể hiểu suy nghĩ đó, nhưng tôi nghĩ một khía cạnh quan trọng cần hiểu với tư cách là một đề xuất là chúng ta không cần phải làm tất cả. Giá trị của đề xuất này không nhất thiết nằm ở việc khôi phục hoàn toàn tất cả các tính năng này mà ở chỗ chúng tôi xem xét toàn diện một bộ lớn các thành phần cơ bản và tự hỏi xem chúng tôi thực sự muốn gì về mặt chức năng.
Đó sẽ là một sự thay đổi hoàn toàn so với ba năm cãi vã và tranh luận vừa qua, nơi chúng tôi tranh cãi về những thay đổi nhỏ, hẹp chỉ có một số chức năng nhất định. Đây giống như một quảng trường nơi mọi người có thể tập hợp lại để cùng nhau xem xét hướng đi trong tương lai. Có thể cuối cùng chúng tôi sẽ khôi phục tất cả các tính năng này, có thể chúng tôi sẽ chỉ kích hoạt một số tính năng vì có sự đồng thuận rằng đó là những tính năng mà tất cả chúng tôi đều đồng ý cần phải bật.
Dù kết quả cuối cùng ra sao thì đây có thể là một sự thay đổi có tác động tích cực đến toàn bộ cuộc trò chuyện về định hướng tương lai của chúng ta. Chúng ta thực sự có thể vạch ra và có được bức tranh toàn cảnh về tình huống, thay vì loay hoay trong khi tranh luận xem nên đi theo con đường mờ ám nào tiếp theo.
Đây hoàn toàn không phải là con đường phía trước mà chúng ta phải đi, nhưng tôi nghĩ đây là cơ hội tốt nhất để chúng ta quyết định con đường nào chúng ta muốn đi. Đã đến lúc bắt đầu làm việc cùng nhau một cách thiết thực và hiệu quả trở lại.
