Chúng ta đã bắt đầu thấy những hạt giống của tiềm năng tầng thứ hai phát triển từ các nguyên tắc cơ bản của tầng cơ sở đã được thêm mới hoặc tối ưu hóa trong thập kỷ đầu tiên. Lightning, mặc dù vẫn phải chịu một số hạn chế khá lớn, nhưng thực sự đang phát triển mạnh mẽ. Và đó chỉ là phiên bản đầu tiên có giới hạn mà hiện đang được chỉ định và triển khai. Hiện nay, đã có các sidechains của các loại khác nhau được triển khai: Liquid, RSK, và thậm chí cả các chuỗi token liên kết với Bitcoin được phát triển bởi Commerceblock. Điều này chỉ là bắt đầu.
Schnorr và Taproot
Ngay phía trên đường chân trời, chúng ta có sự kết hợp của Schnorr và Taproot. Về phía Schnorr, đây là một kế hoạch rẻ hơn nhiều để xác minh sơ đồ chữ ký theo lô, cũng như bước nhảy vọt lớn tiếp theo trong việc tối ưu hóa việc xây dựng các tập lệnh đa chữ ký trong Bitcoin. Multisig bắt đầu chỉ là nhồi nhét tất cả các khóa công khai và tập lệnh cho đa chữ ký trong một đầu ra giao dịch để gửi đến nó và phải bao gồm tất cả những thứ đó trong đầu vào để chi tiêu nó. P2SH đã tối ưu hóa khía cạnh đầu ra, bằng cách bao gồm một hàm băm độ dài không đổi của các khóa công khai và tập lệnh của multisig, tiết kiệm phí cho bất kỳ ai gửi đến địa chỉ đa chữ ký và chỉ để lại chi phí gia tăng cho người gửi. SegWit được cho là đã "tối ưu hóa" hơn nữa bằng cách làm cho chi tiêu UTXOs đa chữ ký rẻ hơn với chiết khấu nhân chứng. Schnorr đưa tất cả sự tối ưu hóa gia tăng này đến mức cực đoan. Bạn kết hợp các khóa công khai riêng lẻ thành một khóa duy nhất, mọi người có thể cộng tác để tạo một chữ ký duy nhất và chỉ cần kiểm tra điều đó. Điều này tạo ra sự tiết kiệm chi phí lớn cho tất cả việc sử dụng multisig, bao gồm các lớp thứ hai như Lightning và các chuỗi bên được liên kết, đồng thời tạo ra lợi ích riêng tư bằng cách làm cho tất cả các UTXO đa chữ ký này không thể phân biệt được với các chữ ký đơn.
Bây giờ điều đó không phải làm mọi thứ trở nên hoàn toàn riêng tư một cách kỳ diệu. Các trạng thái kênh Lightning (giao dịch) vẫn yêu cầu các đường dẫn khóa riêng biệt cho các giao dịch phạt của họ để phản ứng với việc nộp các trạng thái cũ. Điều đó có nghĩa là những thứ đó phải có trong các kịch bản đầu ra tạo ra một dấu vân tay. Taproot giải quyết vấn đề này với phép màu mật mã của nó cho phép bạn cam kết một cây merkle của các điều kiện chi tiêu khác nhau, chỉ cần điều kiện được sử dụng và chứng minh merkle đến gốc merkle để chi tiêu, đến một khóa công khai Schnorr trông bình thường. Bây giờ bạn có thể ẩn đường dẫn kịch bản phạt đó với taproot. Bạn có thể ẩn bất kỳ đường dẫn kịch bản có điều kiện nào với Taproot, chôn dưới một khóa Schnorr trông hoàn toàn bình thường cho phép tất cả các bên đồng ý về một điều gì đó và tạo ra một giao dịch trông hoàn toàn bình thường.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (trước đây SIGHASH_NOINPUT) hy vọng sẽ là nguyên tố mới tiếp theo xuống đường ống. Đây là một định dạng khóa công khai/sighash mới nâng cấp. Cờ Sighash chỉ định các phần của một giao dịch mà chữ ký cam kết. Chức năng này có để bạn có thể làm điều gì đó như ký vào đầu vào và đầu ra của riêng bạn, nhưng cho phép người khác thêm đầu vào và đầu ra của riêng họ vào một giao dịch mà không làm cho nó trở nên không hợp lệ. Nhưng hiện tại, một chữ ký phải cam kết vào một UTXO cụ thể từ một giao dịch cụ thể. SIGHASH_ANYPREVOUT, giữa các thứ khác, sẽ cho phép cam kết một chữ ký vào chỉ một script UTXO, không phải một UTXO cụ thể. Điều này cho phép một cách mới (eltoo) xây dựng trạng thái kênh Lightning mà không cần một khóa phạt hoặc xử lý với trạng thái cũ bằng cách cho phép bên bị lừa chiếm toàn bộ số tiền. Thay vào đó, trạng thái kênh hiện tại có thể đơn giản là chi tiêu lại trạng thái kênh cũ nếu nó thua cuộc đua chi tiêu kép, đảm bảo mọi người nhận được số dư kênh hiện tại của họ trên chuỗi thay vì một số dư cũ trước đó. Bạn thực hiện điều đó bằng cách đơn giản là tái sử dụng cùng một script ở đúng vị trí và sử dụng SIGHASH_ANYPREVOUT.
Điều này loại bỏ rất nhiều rủi ro liên quan đến việc bạn mất trạng thái kênh hiện tại dẫn đến giao dịch phạt lấy tiền của bạn vì một sai lầm chân thành. Nó cũng cho phép RẤT NHIỀU hơn. Bây giờ chúng ta có thể có các kênh Lightning với hơn 2 người tham gia, và thậm chí có thể xếp các “phụ-kênh” lên trên những kênh đó. Ngoài ra, SIGHASH_ANYPREVOUT và eltoo cho phép tạo ra Statechains, một loại cấu trúc kênh liên minh cho phép các bên tham gia mới có thể nhập và thoát hoàn toàn ngoài chuỗi với giả định tin tưởng rằng liên minh sẽ không âm mưu với các bên tham gia trước đó để lừa đảo bất kỳ ai. Điều này mở ra rất nhiều tiềm năng cho những gì mà tôi gọi là “giao thức UTXO tĩnh đa bên.”
OP_CHECKTEMPLATEVERIFY
OP_CTV là một đề xuất của Jeremy Rubin để cho phép một loại “hợp đồng” rất cơ bản trên Bitcoin. Một hợp đồng là các ràng buộc phức tạp hơn đối với việc chi tiêu một đồng tiền ngoài việc ký từ một số khóa nhất định. Loại hợp đồng mà đề xuất của Rubin sẽ thực hiện là một “mẫu”. Đơn giản, điều này cho phép script của một UTXO yêu cầu các đầu ra cụ thể chính xác phải được tạo ra bởi giao dịch chi tiêu. Vì vậy, một khi một UTXO được tạo bằng OP_CTV, thì thông qua sự đồng thuận, UTXO đó phải được chi tiêu vào các địa chỉ cụ thể với số lượng cụ thể được xác định trong script của UTXO đó. Bạn có thể kết nối chúng lại với nhau để một trong những UTXO này bị buộc phải tạo ra một vài UTXO khác, mà sau đó bị buộc phải tạo ra một vài UTXO khác, và cứ như vậy, liên tục.
Điều này có khả năng ứng dụng chung rất lớn ở khắp mọi nơi. Trong môi trường phí cao, một UTXO duy nhất có thể được thực hiện bởi một thực thể lưu ký ** 100% theo các quy tắc đồng thuận ** đảm bảo tất cả tiền của khách hàng của họ sẽ nằm dưới sự kiểm soát của khách hàng, mặc dù họ không có quyền truy cập ngay vào chúng trong thời điểm này. Điều này có rất nhiều sức mạnh tổng hợp tiềm năng với các kênh đa bên (channel factories), trong đó việc "rút tiền" hàng loạt được thực hiện như thế này cũng có thể đồng thời tạo ra và được sử dụng như một nhà máy sản xuất kênh. OP \ _CTV có thể được sử dụng để tạo * các kênh thanh toán ít nhất hoạt động một chiều mà không cần đầu nhận phải tham gia hoặc có khóa trực tuyến để nhận thanh toán * (and nhớ rằng bạn có thể xếp chồng các kênh lên trên mỗi other). Nó thậm chí có thể được sử dụng để cho phép một kênh duy nhất xử lý nhiều HTLC cùng một lúc bằng cách kết hợp chúng lại với nhau với cùng một thủ thuật mà ví dụ đầu tiên với việc rút tiền lưu ký sử dụng. Và thậm chí có thể tạo ra một số tiềm năng cho các loại coinjoin mới.
Đặt Mọi Thứ Vào Một Chỗ
Giả sử tất cả các đề xuất trên được chấp nhận và tích hợp vào Bitcoin, tôi thực sự nghĩ rằng ngoài các nhà phát triển thực sự làm việc trên tuyến đầu của những điều này, mọi người thậm chí còn không có một ý nghĩa nhỏ nhất về loại giao thức và dịch vụ sẽ được xây dựng bằng cách sử dụng các nguyên tắc cơ bản này. Hoặc những điều kỳ lạ không có đường biên rõ ràng giữa dịch vụ hoặc giao thức.
Họ sẽ kích hoạt các kênh đa bên với số lượng người tham gia lý thuyết không giới hạn, có thể xếp chồng các siêu kênh lên đầu với các nhóm con nhỏ hơn của các người tham gia của kênh cơ bản. Các kênh có thể được xây dựng trên cơ sở của những “nhà máy kênh” này cho phép mọi người nhận tiền mà không cần có key trực tuyến cho một ví nóng. Những kênh đa bên này có thể được xếp chồng lên đầu của các kênh liên minh cho phép người tham gia nhập hoặc rời bằng không có hoạt động trên chuỗi! Và cấu trúc của “ghép kênh” sẽ cho phép thanh khoản di chuyển một cách tương đối mượt mà giữa các kênh khác nhau một cách sẽ kích hoạt tất cả các loại điều mà mọi người thậm chí chưa bắt đầu nghĩ đến.
Từ cuối cùng của tôi trong phần này là: điều này chỉ xem xét những gì có thể làm được với những thứ tôi xem là các phần trực tiếp của ngăn cấm giao thức Bitcoin. Bạn có thể làm nhiều hơn nếu bạn bắt đầu xem xét các dịch vụ bảo quản tập trung, và tập hợp nào trong số các tính chất của Bitcoin mà chúng có thể cung cấp mà bỏ qua các rào cản pháp lý hoặc quy định từ việc làm điều đó.
Đây chỉ là Phần 2 trong số 4, đọc phần tiếp theo vào ngày mai
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Thập kỷ Tiếp theo, Phần 2: Con đường phía trước
Chúng ta đã bắt đầu thấy những hạt giống của tiềm năng tầng thứ hai phát triển từ các nguyên tắc cơ bản của tầng cơ sở đã được thêm mới hoặc tối ưu hóa trong thập kỷ đầu tiên. Lightning, mặc dù vẫn phải chịu một số hạn chế khá lớn, nhưng thực sự đang phát triển mạnh mẽ. Và đó chỉ là phiên bản đầu tiên có giới hạn mà hiện đang được chỉ định và triển khai. Hiện nay, đã có các sidechains của các loại khác nhau được triển khai: Liquid, RSK, và thậm chí cả các chuỗi token liên kết với Bitcoin được phát triển bởi Commerceblock. Điều này chỉ là bắt đầu.
Schnorr và Taproot
Ngay phía trên đường chân trời, chúng ta có sự kết hợp của Schnorr và Taproot. Về phía Schnorr, đây là một kế hoạch rẻ hơn nhiều để xác minh sơ đồ chữ ký theo lô, cũng như bước nhảy vọt lớn tiếp theo trong việc tối ưu hóa việc xây dựng các tập lệnh đa chữ ký trong Bitcoin. Multisig bắt đầu chỉ là nhồi nhét tất cả các khóa công khai và tập lệnh cho đa chữ ký trong một đầu ra giao dịch để gửi đến nó và phải bao gồm tất cả những thứ đó trong đầu vào để chi tiêu nó. P2SH đã tối ưu hóa khía cạnh đầu ra, bằng cách bao gồm một hàm băm độ dài không đổi của các khóa công khai và tập lệnh của multisig, tiết kiệm phí cho bất kỳ ai gửi đến địa chỉ đa chữ ký và chỉ để lại chi phí gia tăng cho người gửi. SegWit được cho là đã "tối ưu hóa" hơn nữa bằng cách làm cho chi tiêu UTXOs đa chữ ký rẻ hơn với chiết khấu nhân chứng. Schnorr đưa tất cả sự tối ưu hóa gia tăng này đến mức cực đoan. Bạn kết hợp các khóa công khai riêng lẻ thành một khóa duy nhất, mọi người có thể cộng tác để tạo một chữ ký duy nhất và chỉ cần kiểm tra điều đó. Điều này tạo ra sự tiết kiệm chi phí lớn cho tất cả việc sử dụng multisig, bao gồm các lớp thứ hai như Lightning và các chuỗi bên được liên kết, đồng thời tạo ra lợi ích riêng tư bằng cách làm cho tất cả các UTXO đa chữ ký này không thể phân biệt được với các chữ ký đơn.
Bây giờ điều đó không phải làm mọi thứ trở nên hoàn toàn riêng tư một cách kỳ diệu. Các trạng thái kênh Lightning (giao dịch) vẫn yêu cầu các đường dẫn khóa riêng biệt cho các giao dịch phạt của họ để phản ứng với việc nộp các trạng thái cũ. Điều đó có nghĩa là những thứ đó phải có trong các kịch bản đầu ra tạo ra một dấu vân tay. Taproot giải quyết vấn đề này với phép màu mật mã của nó cho phép bạn cam kết một cây merkle của các điều kiện chi tiêu khác nhau, chỉ cần điều kiện được sử dụng và chứng minh merkle đến gốc merkle để chi tiêu, đến một khóa công khai Schnorr trông bình thường. Bây giờ bạn có thể ẩn đường dẫn kịch bản phạt đó với taproot. Bạn có thể ẩn bất kỳ đường dẫn kịch bản có điều kiện nào với Taproot, chôn dưới một khóa Schnorr trông hoàn toàn bình thường cho phép tất cả các bên đồng ý về một điều gì đó và tạo ra một giao dịch trông hoàn toàn bình thường.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (trước đây SIGHASH_NOINPUT) hy vọng sẽ là nguyên tố mới tiếp theo xuống đường ống. Đây là một định dạng khóa công khai/sighash mới nâng cấp. Cờ Sighash chỉ định các phần của một giao dịch mà chữ ký cam kết. Chức năng này có để bạn có thể làm điều gì đó như ký vào đầu vào và đầu ra của riêng bạn, nhưng cho phép người khác thêm đầu vào và đầu ra của riêng họ vào một giao dịch mà không làm cho nó trở nên không hợp lệ. Nhưng hiện tại, một chữ ký phải cam kết vào một UTXO cụ thể từ một giao dịch cụ thể. SIGHASH_ANYPREVOUT, giữa các thứ khác, sẽ cho phép cam kết một chữ ký vào chỉ một script UTXO, không phải một UTXO cụ thể. Điều này cho phép một cách mới (eltoo) xây dựng trạng thái kênh Lightning mà không cần một khóa phạt hoặc xử lý với trạng thái cũ bằng cách cho phép bên bị lừa chiếm toàn bộ số tiền. Thay vào đó, trạng thái kênh hiện tại có thể đơn giản là chi tiêu lại trạng thái kênh cũ nếu nó thua cuộc đua chi tiêu kép, đảm bảo mọi người nhận được số dư kênh hiện tại của họ trên chuỗi thay vì một số dư cũ trước đó. Bạn thực hiện điều đó bằng cách đơn giản là tái sử dụng cùng một script ở đúng vị trí và sử dụng SIGHASH_ANYPREVOUT.
Điều này loại bỏ rất nhiều rủi ro liên quan đến việc bạn mất trạng thái kênh hiện tại dẫn đến giao dịch phạt lấy tiền của bạn vì một sai lầm chân thành. Nó cũng cho phép RẤT NHIỀU hơn. Bây giờ chúng ta có thể có các kênh Lightning với hơn 2 người tham gia, và thậm chí có thể xếp các “phụ-kênh” lên trên những kênh đó. Ngoài ra, SIGHASH_ANYPREVOUT và eltoo cho phép tạo ra Statechains, một loại cấu trúc kênh liên minh cho phép các bên tham gia mới có thể nhập và thoát hoàn toàn ngoài chuỗi với giả định tin tưởng rằng liên minh sẽ không âm mưu với các bên tham gia trước đó để lừa đảo bất kỳ ai. Điều này mở ra rất nhiều tiềm năng cho những gì mà tôi gọi là “giao thức UTXO tĩnh đa bên.”
OP_CHECKTEMPLATEVERIFY
OP_CTV là một đề xuất của Jeremy Rubin để cho phép một loại “hợp đồng” rất cơ bản trên Bitcoin. Một hợp đồng là các ràng buộc phức tạp hơn đối với việc chi tiêu một đồng tiền ngoài việc ký từ một số khóa nhất định. Loại hợp đồng mà đề xuất của Rubin sẽ thực hiện là một “mẫu”. Đơn giản, điều này cho phép script của một UTXO yêu cầu các đầu ra cụ thể chính xác phải được tạo ra bởi giao dịch chi tiêu. Vì vậy, một khi một UTXO được tạo bằng OP_CTV, thì thông qua sự đồng thuận, UTXO đó phải được chi tiêu vào các địa chỉ cụ thể với số lượng cụ thể được xác định trong script của UTXO đó. Bạn có thể kết nối chúng lại với nhau để một trong những UTXO này bị buộc phải tạo ra một vài UTXO khác, mà sau đó bị buộc phải tạo ra một vài UTXO khác, và cứ như vậy, liên tục.
Điều này có khả năng ứng dụng chung rất lớn ở khắp mọi nơi. Trong môi trường phí cao, một UTXO duy nhất có thể được thực hiện bởi một thực thể lưu ký ** 100% theo các quy tắc đồng thuận ** đảm bảo tất cả tiền của khách hàng của họ sẽ nằm dưới sự kiểm soát của khách hàng, mặc dù họ không có quyền truy cập ngay vào chúng trong thời điểm này. Điều này có rất nhiều sức mạnh tổng hợp tiềm năng với các kênh đa bên (channel factories), trong đó việc "rút tiền" hàng loạt được thực hiện như thế này cũng có thể đồng thời tạo ra và được sử dụng như một nhà máy sản xuất kênh. OP \ _CTV có thể được sử dụng để tạo * các kênh thanh toán ít nhất hoạt động một chiều mà không cần đầu nhận phải tham gia hoặc có khóa trực tuyến để nhận thanh toán * (and nhớ rằng bạn có thể xếp chồng các kênh lên trên mỗi other). Nó thậm chí có thể được sử dụng để cho phép một kênh duy nhất xử lý nhiều HTLC cùng một lúc bằng cách kết hợp chúng lại với nhau với cùng một thủ thuật mà ví dụ đầu tiên với việc rút tiền lưu ký sử dụng. Và thậm chí có thể tạo ra một số tiềm năng cho các loại coinjoin mới.
Đặt Mọi Thứ Vào Một Chỗ
Giả sử tất cả các đề xuất trên được chấp nhận và tích hợp vào Bitcoin, tôi thực sự nghĩ rằng ngoài các nhà phát triển thực sự làm việc trên tuyến đầu của những điều này, mọi người thậm chí còn không có một ý nghĩa nhỏ nhất về loại giao thức và dịch vụ sẽ được xây dựng bằng cách sử dụng các nguyên tắc cơ bản này. Hoặc những điều kỳ lạ không có đường biên rõ ràng giữa dịch vụ hoặc giao thức.
Họ sẽ kích hoạt các kênh đa bên với số lượng người tham gia lý thuyết không giới hạn, có thể xếp chồng các siêu kênh lên đầu với các nhóm con nhỏ hơn của các người tham gia của kênh cơ bản. Các kênh có thể được xây dựng trên cơ sở của những “nhà máy kênh” này cho phép mọi người nhận tiền mà không cần có key trực tuyến cho một ví nóng. Những kênh đa bên này có thể được xếp chồng lên đầu của các kênh liên minh cho phép người tham gia nhập hoặc rời bằng không có hoạt động trên chuỗi! Và cấu trúc của “ghép kênh” sẽ cho phép thanh khoản di chuyển một cách tương đối mượt mà giữa các kênh khác nhau một cách sẽ kích hoạt tất cả các loại điều mà mọi người thậm chí chưa bắt đầu nghĩ đến.
Từ cuối cùng của tôi trong phần này là: điều này chỉ xem xét những gì có thể làm được với những thứ tôi xem là các phần trực tiếp của ngăn cấm giao thức Bitcoin. Bạn có thể làm nhiều hơn nếu bạn bắt đầu xem xét các dịch vụ bảo quản tập trung, và tập hợp nào trong số các tính chất của Bitcoin mà chúng có thể cung cấp mà bỏ qua các rào cản pháp lý hoặc quy định từ việc làm điều đó.
Đây chỉ là Phần 2 trong số 4, đọc phần tiếp theo vào ngày mai