Bất chấp phạm vi của đề xuất, lý do tại sao "sự phục hồi kịch bản tuyệt vời" của Rusty Russell có thể là con đường phía trước cho sự phát triển của Bitcoin?
Khối kỳ lân 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 đã làm việc rộng rãi về phát triển nhân Linux và đã tham gia vào nhiều dự án phát triển cốt lõi long Bitcoin.
Bitcoin ban đầu được thiết kế để có một ngôn ngữ kịch bản hoàn chỉnh được thiết kế để 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 mà người dùng có thể đưa 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à một khi phiên bản 0.1 được phát hành, thiết kế cốt lõi được xác định cho phần còn lại của vòng đời. 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ợ và trường dữ liệu đặc biệt, dù được sử dụng hay không, dẫn đến các trường hợp đặc biệt dài nhất. Giải pháp là một kịch bản khái quát hóa vấn đề để cả hai bên có thể mô tả các giao dịch của họ với các điều kiện cụ thể mà mạng Nút đánh giá hoặc xác nhận dựa trên các điều kiện đó. - Satoshi Nakamoto, ngày 17 tháng 6 năm 2010
Toàn bộ mục đích của anh ấy là cung cấp cho người dùng một ngôn ngữ đủ phổ biến để họ tổ chức các loại giao dịch theo ý muốn. Đó là, quần short để người dùng thiết kế và thử nghiệm cách viết tiền của riêng họ.
Trước khi biến mất, Satoshi Nakamoto đã xóa 15 mã hoạt động 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ào ngăn xếp công cụ kịch bản giới hạn kích thước của các khối dữ liệu có thể bị thao tác (520 byte). Điều này là do anh ta thực sự đã làm hỏng, để lại rất nhiều cách mà các tập lệnh phức tạp có thể được sử dụng để thực hiện các cuộc tấn công DOS vào toàn bộ mạng (gửi một số lượng lớn yêu cầu spam, khiến mạng bị sập), tạo ra các giao dịch lớn và tốn kém sẽ làm sập các nút.
Các Mã hoạt động này không bị xóa vì Satoshi Nakamoto nghĩ rằng các tính năng này nguy hiểm hoặc mọi người không nên sử dụng chúng để xây dựng thứ gì đó có thể đạt được, mà chỉ đơn giản là (ít nhất là trên bề mặt) vì rủi ro mà chúng gây ra cho toàn bộ mạng mà không bị hạn chế về tài nguyên, chẳng hạn như chi phí xác thực tồi tệ nhất mà họ có thể áp đặt cho mạng mà không có giới hạn.
Kể từ đó, mỗi bản nâng cấp của Bitcoin đã kết thúc là một tối ưu hóa chức năng của các tính năng còn lại, sửa chữa các lỗi ít nghiêm trọng khác Satoshi Nakamoto để 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 còn lại của chúng tôi.
Phục hồi tập lệnh tuyệt vời
Tại hội nghị Austin Bitcoin++ vào đầu tháng Năm, nhà phát triển Lighting Network cốt lõi 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 ông về cơ bản đã đưa ra ý tưởng kích hoạt lại Mã thao tác khao khát lớn mà Satoshi Nakamoto đã vô hiệu hóa trước khi nó 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 (Taproot là một bản nâng cấp lớn cho Bitcoin nhằm cải thiện quyền riêng tư, bảo mật và khả năng mở rộng), không gian phát triển thực sự hơi vô mục đích. Chúng ta đều biết rằng Bitcoin không đủ khả năng mở rộng để thực sự cung cấp các dịch vụ tự chủ cho bất kỳ quy mô dân số lớn nào trên thế giới và thậm chí có thể không thể cung cấp khả năng mở rộng cho các nhà cung cấp dịch vụ có thể vượt qua những người giám sát và nhà cung cấp dịch vụ rất lớn và không thể thực sự thoát khỏi những ràng buộc long của chính phủ, theo cách giảm thiểu sự tin tưởng hoặc quyền giám sát.
Bài viết này chỉ ra trình độ kỹ thuật của Bitcoin, đây không phải là vấn đề cần tranh luận. Câu hỏi đáng tranh cãi là làm thế nào để khắc phục lỗ hổng này, đây là một chủ đề rất gây tranh cãi. Kể từ khi Taproot được giới thiệu, mọi người đã đưa ra các đề xuất rất hẹp nhằm giải quyết các vấn đề chỉ có thể đạt được cho 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 trong các giao dịch khác nhau, long như tập lệnh và số tiền được nhập là như nhau và đề xuất này được thiết kế đặc biệt để tối ưu hóa Lighting Network và các phiên bản người theo lệnh long của nó. CHECKTEMPLATEVERIFY (CTV) là một đề xuất yêu cầu các đồng tiền cứng 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 và đề 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 để đặt "thời gian chờ" cho giải pháp lưu trữ lạnh, để người dùng có thể "tìm nạp" từ kho lạnh bằng cách gửi nó đến cài đặt long lạnh hơn để ngăn Chìa khoá bảo mật của họ bị xâm phạm.
Có những đề xuất dài nhất khác, nhưng tôi nghĩ bạn đã hiểu ý chính. Trong vài năm qua, mỗi đề xuất đã được thiết kế để 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 này được coi là mong muốn. Đó là nguyên nhân gốc rễ của lý do tại sao các cuộc thảo luận này đã không đạt được tiến bộ. 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.
Không ai khác ngoài nhà tài trợ của đề xuất tin rằng bất kỳ đề xuất nào cũng đủ toàn diện để được coi là một bước tiếp theo hợp lý.
Đây là logic đằng sau "Great Script Recovery". Bằng cách đẩy và phân tích sự phục hồi hoàn toàn của các tập lệnh, như Satoshi Nakamoto thiết kế ban đầu, chúng ta thực sự có thể cố gắng khám phá toàn bộ các tính năng ngắn mà chúng ta cần, thay vì tranh cãi và đấu đá về việc tiện ích mở rộng tính năng nhỏ nào đủ tốt ngay bây giờ.
OPCODES (Mã thao tác)
OP_CAT: Lấy hai phần dữ liệu từ ngăn xếp và cộng chúng lại với nhau để 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 các byte có độ dài đó và đặt lại vào 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à loại bỏ các byte có độ dài được chỉ định từ bên này hay bên kia.
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 các thao tác bit tương ứng trên nó.
OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV và OP_MOD: Toán tử toán học cho phép nhân, chia và phép toán modulo (trả về phần còn lại của phép chia).
Ngoài việc niêm yết Mã hoạt động để khôi phục ở trên, Rusty Russell đề xuất thêm ba Mã hoạt động được thiết kế để đơn giản hóa việc kết hợp các Mã hoạt động khác nhau:
OP_CTV (hoặc TXHASH/ Mã thao tác tương đương): Cho phép thực thi chi tiết một số phần nhất định của giao dịch phải được xác định chính xác như được xác định trước.
CSFS: Cho phép chữ ký được xác minh, không chỉ cho toàn bộ giao dịch, yêu cầu một số phần nhất định của tập lệnh hoặc dữ liệu được sử dụng phải được đăng nhập lệnh được thực thi.
OP_TWEAKVERIFY: Xác thực các hoạt động dựa trên Schnorr liên quan đến Khóa công khai, chẳng hạn như cộng hoặc trừ các Khóa công khai riêng lẻ khỏi 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 đơn phương để lại đầu ra giao dịch chưa sử dụng chung (UTXO), tất cả tiền của những người tham gia khác được gửi đến một khóa công khai tổng hợp không yêu cầu ký kết của bên rời đi để thực hiện chi tiêu hợp tác.
Tại sao chúng ta làm điều này
Layer 2 mạng về cơ bản là phần mở rộng của lớp cơ sở của Bitcoin và chúng bị hạn chế về mặt chức năng bởi các chức năng của lớp cơ sở. Lighting Network yêu cầu ba Soft Fork riêng biệt trước khi chúng thực sự có thể được triển khai: CHECKLOCKTIMEVERIFY (CLTV), checksequenceverify (csv) và SegWit (Bằng chứng tách biệt).
Nếu không có lớp cơ sở linh hoạt hơn, bạn không thể xây dựng mạng lớp 2 linh hoạt hơn. Lối tắt duy nhất là tin tưởng các bên thứ ba, điều này rất đơn giản và dễ hiểu, và tôi hy vọng tất cả chúng ta đều mong muốn loại bỏ các bên thứ ba đáng tin cậy khỏi mọi khía cạnh tương tác với Bitcoin ở quy mô càng nhiều càng tốt.
Chúng ta cần có khả năng làm điều gì đó hiện không thể thực hiện được ở lệnh hợp nhất an toàn nhiều người thành một đầu ra giao dịch không sử dụng (UTXO) duy nhất và có thể thực hiện một cách đáng tin cậy trên lớp cơ sở. Sự linh hoạt hiện tại của Bitcoin Script là không đủ. Ở cấp độ cơ bản nhất, chúng ta cần các hợp đồng và chúng ta 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 các giao dịch để đảm bảo rằng người dùng thoát khỏi UTXO của chính họ 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.
Ở một viễn cảnh cao hơn, đây là những gì 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ề chính giao dịch chi tiêu, chẳng hạn như "số tiền này sẽ chuyển đến khóa công khai này của một số đầu ra". Đ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 công khai của những người dùng khác, trong trường hợp những người tham gia khác gây mất tiền.
Chuyển tiếp dữ liệu: Giả sử chúng ta lấy khái niệm về một UTXO duy nhất, ví dụ, với một số lượng lớn người, rằng bất kỳ ai cũng có thể đến và đi khi họ muốn. Trong trường hợp này, chúng ta cần một cách để theo dõi ai có tiền dài nhất hoặc ít hơn, thường sử dụng Cây Merkle và gốc 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 cho 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 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 công khai tổng hợp có thể được xác minh trên ngăn xếp. Trong chương trình chia sẻ Đầu ra Giao dịch Chưa sử dụng (UTXO), mục tiêu của chúng tôi là tạo điều kiện thuận lợi cho sự hợp tác và dòng tiền hiệu quả thông qua một 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 chung, chúng ta cần xóa Khóa công khai cá nhân của họ khỏi Khóa công khai 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, tùy chọn duy nhất là xác minh rằng việc trừ một khóa công khai khỏi khóa công khai tổng hợp sẽ tạo ra một khóa công khai hợp lệ bao gồm các khóa công khai riêng lẻ còn lại.
Làm thế nào để an toàn: VAROPS Như tôi đã nói ở trên, lý do vô hiệu hóa tất cả các Mã hoạt động này là để giải quyết các cuộc tấn công DOS (khiến mạng bị sập bằng cách gửi một số lượng lớn yêu cầu spam), điều này có thể khiến các Node tạo nên mạng bị sập. Một cách để giải quyết vấn đề này là giới hạn số lượng tài nguyên có thể được sử dụng bởi bất kỳ Mã hoạt động nào trong số này.
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 như vậy, được gọi là ngân sách hoạt động chữ ký (sigops). Mỗi lần sử dụng kiểm tra chữ ký Mã thao tác tiêu tốn một "ngân sách" nhất định, nghĩa 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í mà giao dịch có thể tạo ra để xác thực khối.
Taproot thay đổi cách làm việc này, không người theo lệnh long sử dụng một giới hạn Khối toàn cầu duy nhất, mà thay vào đó 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. Điều này về cơ bản bằng với cùng một giới hạn toàn cầu, nhưng nó dễ hiểu hơn rằng mỗi giao dịch có long ít sigop có sẵn.
Sự thay đổi giới hạn sigops (hoạt động chữ ký) của Taproot để xử lý mỗi giao dịch mở ra khả năng tiếp cận khái quát hóa, đó là những gì Rusty Russell đề xuất về giới hạn varops. Ý tưởng là gán chi phí cho mỗi Mã thao tác được kích hoạt lại để tài khoản cho trường hợp xấu nhất mà mỗi Mã thao tác có thể tạo ra, tức là chi phí tính toán đắt nhất phát sinh tại thời điểm xác nhận. Bằng cách này, mỗi Mã thao tác 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 nhận. Đ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ã thao tác này, do đó, suy luận có thể được tạo điều kiện trong khi vẫn tích lũy đến giới hạn toàn cầu ngầm trên mỗi Khối.
Điều này sẽ giải quyết cuộc tấn công DOS (bằng cách gửi rất nhiều yêu cầu spam, khiến mạng bị sập) vì các giao dịch spam này và nguyên nhân khiến Satoshi Nakamoto ban đầu vô hiệu hóa tất cả các Mã hoạt động đó.
Động lực để tiến về phía trước
Tôi chắc chắn rằng lâu nhất trong số các bạn sẽ nghĩ, "Đây là quá nhiều thay đổi." Tôi có thể hiểu điều đó, nhưng tôi nghĩ một khía cạnh quan trọng cần hiểu như một đề xuất 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 là tất cả các tính năng này được khôi phục hoàn toàn, mà là chúng ta sẽ xem xét toàn diện một bộ các thành phần nền tảng rộng lớn và tự hỏi mình thực sự muốn gì về chức năng.
Đó sẽ là một sự thay đổi hoàn toàn từ ba năm tranh cãi và tranh luận vừa qua rằng chúng ta chỉ tranh luận về những thay đổi nhỏ hẹp, hẹp chỉ có một số chức năng nhất định. Nó giống như một quảng trường nơi mọi người có thể đến với nhau và nhìn về hướng đi của tương lai. Có lẽ cuối cùng chúng tôi sẽ khôi phục tất cả các tính năng này hoặc có thể cuối cùng chúng tôi sẽ chỉ kích hoạt một vài trong số chúng, bởi vì Nhận thức chung là đây là những tính năng mà tất cả chúng ta đều đồng ý cần phải bật.
Bất kể kết quả cuối cùng là gì, đây có thể là một thay đổi 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 một bức tranh đầy đủ về tình hình, thay vì mò mẫm theo cách của chúng ta xung quanh tranh luận về con đường âm u nào sẽ đi tiếp theo.
Đó không phải là con đường chúng ta phải đi, nhưng tôi nghĩ đó 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 lần nữa một cách thiết thực và hiệu quả.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Phục hồi kịch bản tuyệt vời: Con đường phía trước của Bitcoin
TÁC GIẢ GỐC: SHINOBI
Biên soạn gốc: Khối unicorn
Bất chấp phạm vi của đề xuất, lý do tại sao "sự phục hồi kịch bản tuyệt vời" của Rusty Russell có thể là con đường phía trước cho sự phát triển của Bitcoin?
Khối kỳ lân 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 đã làm việc rộng rãi về phát triển nhân Linux và đã tham gia vào nhiều dự án phát triển cốt lõi long Bitcoin.
Bitcoin ban đầu được thiết kế để có một ngôn ngữ kịch bản hoàn chỉnh được thiết kế để 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 mà người dùng có thể đưa 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à một khi phiên bản 0.1 được phát hành, thiết kế cốt lõi được xác định cho phần còn lại của vòng đời. 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ợ và trường dữ liệu đặc biệt, dù được sử dụng hay không, dẫn đến các trường hợp đặc biệt dài nhất. Giải pháp là một kịch bản khái quát hóa vấn đề để cả hai bên có thể mô tả các giao dịch của họ với các điều kiện cụ thể mà mạng Nút đánh giá hoặc xác nhận dựa trên các điều kiện đó. - Satoshi Nakamoto, ngày 17 tháng 6 năm 2010
Toàn bộ mục đích của anh ấy là cung cấp cho người dùng một ngôn ngữ đủ phổ biến để họ tổ chức các loại giao dịch theo ý muốn. Đó là, quần short để người dùng thiết kế và thử nghiệm cách viết tiền của riêng họ.
Trước khi biến mất, Satoshi Nakamoto đã xóa 15 mã hoạt động 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ào ngăn xếp công cụ kịch bản giới hạn kích thước của các khối dữ liệu có thể bị thao tác (520 byte). Điều này là do anh ta thực sự đã làm hỏng, để lại rất nhiều cách mà các tập lệnh phức tạp có thể được sử dụng để thực hiện các cuộc tấn công DOS vào toàn bộ mạng (gửi một số lượng lớn yêu cầu spam, khiến mạng bị sập), tạo ra các giao dịch lớn và tốn kém sẽ làm sập các nút.
Các Mã hoạt động này không bị xóa vì Satoshi Nakamoto nghĩ rằng các tính năng này nguy hiểm hoặc mọi người không nên sử dụng chúng để xây dựng thứ gì đó có thể đạt được, mà chỉ đơn giản là (ít nhất là trên bề mặt) vì rủi ro mà chúng gây ra cho toàn bộ mạng mà không bị hạn chế về tài nguyên, chẳng hạn như chi phí xác thực tồi tệ nhất mà họ có thể áp đặt cho mạng mà không có giới hạn.
Kể từ đó, mỗi bản nâng cấp của Bitcoin đã kết thúc là một tối ưu hóa chức năng của các tính năng còn lại, sửa chữa các lỗi ít nghiêm trọng khác Satoshi Nakamoto để 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 còn lại của chúng tôi.
Phục hồi tập lệnh tuyệt vời
Tại hội nghị Austin Bitcoin++ vào đầu tháng Năm, nhà phát triển Lighting Network cốt lõi 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 ông về cơ bản đã đưa ra ý tưởng kích hoạt lại Mã thao tác khao khát lớn mà Satoshi Nakamoto đã vô hiệu hóa trước khi nó 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 (Taproot là một bản nâng cấp lớn cho Bitcoin nhằm cải thiện quyền riêng tư, bảo mật và khả năng mở rộng), không gian phát triển thực sự hơi vô mục đích. Chúng ta đều biết rằng Bitcoin không đủ khả năng mở rộng để thực sự cung cấp các dịch vụ tự chủ cho bất kỳ quy mô dân số lớn nào trên thế giới và thậm chí có thể không thể cung cấp khả năng mở rộng cho các nhà cung cấp dịch vụ có thể vượt qua những người giám sát và nhà cung cấp dịch vụ rất lớn và không thể thực sự thoát khỏi những ràng buộc long của chính phủ, theo cách giảm thiểu sự tin tưởng hoặc quyền giám sát.
Bài viết này chỉ ra trình độ kỹ thuật của Bitcoin, đây không phải là vấn đề cần tranh luận. Câu hỏi đáng tranh cãi là làm thế nào để khắc phục lỗ hổng này, đây là một chủ đề rất gây tranh cãi. Kể từ khi Taproot được giới thiệu, mọi người đã đưa ra các đề xuất rất hẹp nhằm giải quyết các vấn đề chỉ có thể đạt được cho 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 trong các giao dịch khác nhau, long như tập lệnh và số tiền được nhập là như nhau và đề xuất này được thiết kế đặc biệt để tối ưu hóa Lighting Network và các phiên bản người theo lệnh long của nó. CHECKTEMPLATEVERIFY (CTV) là một đề xuất yêu cầu các đồng tiền cứng 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 và đề 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 để đặt "thời gian chờ" cho giải pháp lưu trữ lạnh, để người dùng có thể "tìm nạp" từ kho lạnh bằng cách gửi nó đến cài đặt long lạnh hơn để ngăn Chìa khoá bảo mật của họ bị xâm phạm.
Có những đề xuất dài nhất khác, nhưng tôi nghĩ bạn đã hiểu ý chính. Trong vài năm qua, mỗi đề xuất đã được thiết kế để 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 này được coi là mong muốn. Đó là nguyên nhân gốc rễ của lý do tại sao các cuộc thảo luận này đã không đạt được tiến bộ. 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.
Không ai khác ngoài nhà tài trợ của đề xuất tin rằng bất kỳ đề xuất nào cũng đủ toàn diện để được coi là một bước tiếp theo hợp lý.
Đây là logic đằng sau "Great Script Recovery". Bằng cách đẩy và phân tích sự phục hồi hoàn toàn của các tập lệnh, như Satoshi Nakamoto thiết kế ban đầu, chúng ta thực sự có thể cố gắng khám phá toàn bộ các tính năng ngắn mà chúng ta cần, thay vì tranh cãi và đấu đá về việc tiện ích mở rộng tính năng nhỏ nào đủ tốt ngay bây giờ.
OPCODES (Mã thao tác)
Ngoài việc niêm yết Mã hoạt động để khôi phục ở trên, Rusty Russell đề xuất thêm ba Mã hoạt động được thiết kế để đơn giản hóa việc kết hợp các Mã hoạt động khác nhau:
OP_CTV (hoặc TXHASH/ Mã thao tác tương đương): Cho phép thực thi chi tiết một số phần nhất định của giao dịch phải được xác định chính xác như được xác định trước.
CSFS: Cho phép chữ ký được xác minh, không chỉ cho toàn bộ giao dịch, yêu cầu một số phần nhất định của tập lệnh hoặc dữ liệu được sử dụng phải được đăng nhập lệnh được thực thi.
OP_TWEAKVERIFY: Xác thực các hoạt động dựa trên Schnorr liên quan đến Khóa công khai, chẳng hạn như cộng hoặc trừ các Khóa công khai riêng lẻ khỏi 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 đơn phương để lại đầu ra giao dịch chưa sử dụng chung (UTXO), tất cả tiền của những người tham gia khác được gửi đến một khóa công khai tổng hợp không yêu cầu ký kết của bên rời đi để thực hiện chi tiêu hợp tác.
Tại sao chúng ta làm điều này
Layer 2 mạng về cơ bản là phần mở rộng của lớp cơ sở của Bitcoin và chúng bị hạn chế về mặt chức năng bởi các chức năng của lớp cơ sở. Lighting Network yêu cầu ba Soft Fork riêng biệt trước khi chúng thực sự có thể được triển khai: CHECKLOCKTIMEVERIFY (CLTV), checksequenceverify (csv) và SegWit (Bằng chứng tách biệt).
Nếu không có lớp cơ sở linh hoạt hơn, bạn không thể xây dựng mạng lớp 2 linh hoạt hơn. Lối tắt duy nhất là tin tưởng các bên thứ ba, điều này rất đơn giản và dễ hiểu, và tôi hy vọng tất cả chúng ta đều mong muốn loại bỏ các bên thứ ba đáng tin cậy khỏi mọi khía cạnh tương tác với Bitcoin ở quy mô càng nhiều càng tốt.
Chúng ta cần có khả năng làm điều gì đó hiện không thể thực hiện được ở lệnh hợp nhất an toàn nhiều người thành một đầu ra giao dịch không sử dụng (UTXO) duy nhất và có thể thực hiện một cách đáng tin cậy trên lớp cơ sở. Sự linh hoạt hiện tại của Bitcoin Script là không đủ. Ở cấp độ cơ bản nhất, chúng ta cần các hợp đồng và chúng ta 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 các giao dịch để đảm bảo rằng người dùng thoát khỏi UTXO của chính họ 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.
Ở một viễn cảnh cao hơn, đây là những gì 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ề chính giao dịch chi tiêu, chẳng hạn như "số tiền này sẽ chuyển đến khóa công khai này của một số đầu ra". Đ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 công khai của những người dùng khác, trong trường hợp những người tham gia khác gây mất tiền.
Chuyển tiếp dữ liệu: Giả sử chúng ta lấy khái niệm về một UTXO duy nhất, ví dụ, với một số lượng lớn người, rằng bất kỳ ai cũng có thể đến và đi khi họ muốn. Trong trường hợp này, chúng ta cần một cách để theo dõi ai có tiền dài nhất hoặc ít hơn, thường sử dụng Cây Merkle và gốc 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 cho 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 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 công khai tổng hợp có thể được xác minh trên ngăn xếp. Trong chương trình chia sẻ Đầu ra Giao dịch Chưa sử dụng (UTXO), mục tiêu của chúng tôi là tạo điều kiện thuận lợi cho sự hợp tác và dòng tiền hiệu quả thông qua một 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 chung, chúng ta cần xóa Khóa công khai cá nhân của họ khỏi Khóa công khai 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, tùy chọn duy nhất là xác minh rằng việc trừ một khóa công khai khỏi khóa công khai tổng hợp sẽ tạo ra một khóa công khai hợp lệ bao gồm các khóa công khai riêng lẻ còn lại.
Làm thế nào để an toàn: VAROPS Như tôi đã nói ở trên, lý do vô hiệu hóa tất cả các Mã hoạt động này là để giải quyết các cuộc tấn công DOS (khiến mạng bị sập bằng cách gửi một số lượng lớn yêu cầu spam), điều này có thể khiến các Node tạo nên mạng bị sập. Một cách để giải quyết vấn đề này là giới hạn số lượng tài nguyên có thể được sử dụng bởi bất kỳ Mã hoạt động nào trong số này.
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 như vậy, được gọi là ngân sách hoạt động chữ ký (sigops). Mỗi lần sử dụng kiểm tra chữ ký Mã thao tác tiêu tốn một "ngân sách" nhất định, nghĩa 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í mà giao dịch có thể tạo ra để xác thực khối.
Taproot thay đổi cách làm việc này, không người theo lệnh long sử dụng một giới hạn Khối toàn cầu duy nhất, mà thay vào đó 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. Điều này về cơ bản bằng với cùng một giới hạn toàn cầu, nhưng nó dễ hiểu hơn rằng mỗi giao dịch có long ít sigop có sẵn.
Sự thay đổi giới hạn sigops (hoạt động chữ ký) của Taproot để xử lý mỗi giao dịch mở ra khả năng tiếp cận khái quát hóa, đó là những gì Rusty Russell đề xuất về giới hạn varops. Ý tưởng là gán chi phí cho mỗi Mã thao tác được kích hoạt lại để tài khoản cho trường hợp xấu nhất mà mỗi Mã thao tác có thể tạo ra, tức là chi phí tính toán đắt nhất phát sinh tại thời điểm xác nhận. Bằng cách này, mỗi Mã thao tác 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 nhận. Đ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ã thao tác này, do đó, suy luận có thể được tạo điều kiện trong khi vẫn tích lũy đến giới hạn toàn cầu ngầm trên mỗi Khối.
Điều này sẽ giải quyết cuộc tấn công DOS (bằng cách gửi rất nhiều yêu cầu spam, khiến mạng bị sập) vì các giao dịch spam này và nguyên nhân khiến Satoshi Nakamoto ban đầu vô hiệu hóa tất cả các Mã hoạt động đó.
Động lực để tiến về phía trước
Tôi chắc chắn rằng lâu nhất trong số các bạn sẽ nghĩ, "Đây là quá nhiều thay đổi." Tôi có thể hiểu điều đó, nhưng tôi nghĩ một khía cạnh quan trọng cần hiểu như một đề xuất 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 là tất cả các tính năng này được khôi phục hoàn toàn, mà là chúng ta sẽ xem xét toàn diện một bộ các thành phần nền tảng rộng lớn và tự hỏi mình thực sự muốn gì về chức năng.
Đó sẽ là một sự thay đổi hoàn toàn từ ba năm tranh cãi và tranh luận vừa qua rằng chúng ta chỉ tranh luận về những thay đổi nhỏ hẹp, hẹp chỉ có một số chức năng nhất định. Nó giống như một quảng trường nơi mọi người có thể đến với nhau và nhìn về hướng đi của tương lai. Có lẽ cuối cùng chúng tôi sẽ khôi phục tất cả các tính năng này hoặc có thể cuối cùng chúng tôi sẽ chỉ kích hoạt một vài trong số chúng, bởi vì Nhận thức chung là đây là những tính năng mà tất cả chúng ta đều đồng ý cần phải bật.
Bất kể kết quả cuối cùng là gì, đây có thể là một thay đổi 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 một bức tranh đầy đủ về tình hình, thay vì mò mẫm theo cách của chúng ta xung quanh tranh luận về con đường âm u nào sẽ đi tiếp theo.
Đó không phải là con đường chúng ta phải đi, nhưng tôi nghĩ đó 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 lần nữa một cách thiết thực và hiệu quả.