MCCV: Một chiếc két sắt đầy đủ tính năng chỉ sử dụng mô-đun trung tâm (CTV).

Tác giả: ademan

Nguồn: https://delvingbitcoin.org/t/ctv-only-vault-concept-v0-1-0-release/2539

Tôi rất vui mừng thông báo về việc phát hành phiên bản đầu tiên của MCCV – ý tưởng của tôi về một “ két sắt CTV phức tạp hơn ”; nó được phát triển bằng cách sử dụng BIP-119 OP_CHECKTEMPLATEVERIFY (OP_CTV). MCCV chứng minh rằng một hợp đồng két sắt đầy đủ chức năng có thể được xây dựng chỉ bằng OP_CHECKTEMPLATEVERIFY , mà không cần dựa vào các mã lệnh giao ước biểu đạt hơn. Mặc dù thiết kế cuối cùng đòi hỏi nhiều tính toán và không thực sự tiện lợi, nhưng nó đã cung cấp thành công các tính năng như gửi tiền, rút ​​tiền trì hoãn, phục hồi, kiểm soát tốc độ rút tiền và các thao tác két sắt lặp đi lặp lại.

Tóm lại, tiền được gửi vào một kho tiền từ ví thông thường theo các mức định trước; việc rút tiền cũng được thực hiện theo các mức định trước, và thời gian khóa tương đối sẽ kéo dài thêm với mỗi lần rút tiền. Thời gian khóa tương đối này tạo ra một khoảng thời gian thử thách, trong đó các khoản rút tiền đang chờ xử lý và số tiền còn lại trong kho tiền có thể được chuyển đổi sang khóa phục hồi; khóa phục hồi sau đó có thể được sử dụng với thiết bị lưu trữ an toàn hơn.

Vì thời gian khóa kéo dài tỷ lệ thuận với số lượng giao dịch rút tiền, hợp đồng hộp ký gửi an toàn này cung cấp giới hạn tốc độ rút tiền được thực thi bằng cơ chế đồng thuận, có thể giảm thiểu tổn thất tiềm tàng.

Tổng quan

Lưu ý : Đây là phần mềm thử nghiệm chứng minh tính khả thi, chỉ có thể sử dụng trên các mạng thử nghiệm như signet (hoặc regtest).

Phiên bản hiện tại là một phần mềm giao diện dòng lệnh hoạt động, một bản thử nghiệm, được viết bằng Rust và phụ thuộc vào BDK và rust-bitcoin . Nó chạy trên regtest và signet bằng Bitcoin Inquisition v29; Bitcoin Inquisition hỗ trợ OP_CHECKTEMPLATEVERIFY , TRUC (giao dịch bị hạn chế về cấu trúc liên kết trước khi xác nhận) và "neo tạm thời".

Phiên bản này hỗ trợ:

• Tạo một nơi an toàn
• Hãy sử dụng ví nóng để nhận và chi tiền.
• Gửi một khoản tiền cố định theo từng giai đoạn vào két sắt.
• Khởi tạo các khoản rút tiền trì hoãn với mức tăng cố định.
• Chuyển các khoản rút tiền đã đến hạn sang ví nóng.
• Khôi phục toàn bộ két sắt về khóa phục hồi được lưu trữ lạnh.
• Địa chỉ kho lưu trữ GitHub: GitHub - LNHANCE-Expedition/mccv: More Complicated CTV Vault · GitHub
• Hướng dẫn sử dụng: mccv/docs/user-guide.md tại master · LNHANCE-Expedition/mccv · GitHub
• Chi tiết giao thức (Đang phát triển): mccv/docs/protocol.md tại nhánh master · LNHANCE-Expedition/mccv · GitHub

đặc điểm

Ngăn chặn việc rút tiền trái phép

Cũng giống như tất cả các loại két sắt khác, tiền rút từ loại két sắt này sẽ trải qua một cửa sổ xác thực: trong thời gian này, người dùng có thể chuyển số tiền đã rút và bất kỳ số tiền còn lại nào trong két sắt sang khóa khôi phục.

Kiểm soát tốc độ rút

Loại két sắt này không chỉ cung cấp cách thức thu hồi tiền trong trường hợp truy cập trái phép mà còn bổ sung thêm giới hạn tốc độ rút tiền được thực thi bằng cơ chế đồng thuận.

Lần thao tác

Thỏa thuận này hỗ trợ một số lượng đáng kể nhưng có giới hạn các giao dịch gửi và rút tiền trên cùng một két sắt. Điều này làm cho thiết kế két sắt này linh hoạt hơn nhiều so với thiết kế két sắt đơn lẻ.

Hỗ trợ

Loại két sắt này có thể sao lưu dữ liệu thành một tập dữ liệu rất nhỏ, có kích thước không đổi.

Những thiếu sót nghiêm trọng

độ phức tạp

Giao thức này có thể tạo ra hàng triệu giao dịch; nó đòi hỏi kiểm tra và kiểm toán chất lượng mã nghiêm ngặt để đạt được mức độ tin cậy cơ bản. Hơn nữa, chính sự phức tạp của nó đã là một rủi ro, khiến giao thức này kém hấp dẫn hơn đối với trường hợp sử dụng mục tiêu của nó—các khoản tiền lớn. Tuy nhiên, rủi ro đáng lo ngại nhất này có thể được giảm thiểu ở một mức độ nào đó bằng cách có một kho lưu trữ lạnh/khóa phục hồi dự phòng.

Việc tính toán rất khó khăn.

Gánh nặng tính toán tăng lên theo độ chi tiết của các khoản tiền gửi, số lượng khoản tiền được phép rút/gửi đồng thời và tổng số thao tác được hỗ trợ bởi kho tiền. Bất kỳ biện pháp nào cải thiện trải nghiệm người dùng đều sẽ dẫn đến gánh nặng tính toán tăng lên và phí giao dịch trên Chuỗi.

Quy trình tạo ra két sắt ủy thác

Độ phức tạp tính toán của phương pháp này dẫn đến nhu cầu thiết lập lòng tin. Thiết bị tạo ra két sắt phải đủ mạnh để liệt kê các thao tác mà người dùng mong muốn, và nó cũng phải đáng tin cậy. Hiện tại, việc tạo ra các phiên bản két sắt với các thông số thực tế đòi hỏi phần cứng có hiệu năng tương đương với các máy tính cá nhân hoặc thiết bị di động thương mại mới nhất, nhưng các hệ thống này khó có thể tin tưởng. Máy tính cá nhân ngoại tuyến đáp ứng tốt nhất yêu cầu này, nhưng bản thân máy tính cá nhân ngoại tuyến cũng đã có thể đáp ứng đáng kể các yêu cầu bảo mật của người dùng mà không cần đến bất kỳ két sắt phức tạp nào. STARK có thể xác minh thực tế các két sắt trong một thiết bị ký phần cứng, mà tôi cho rằng là một hướng nghiên cứu quan trọng trong tương lai.

Việc rút tiền cần thực hiện hai bước.

Vì mỗi vault được tính toán trước, tiền không thể được rút trực tiếp cho người nhận. Thay vào đó, các khoản rút tiền đã đến hạn có thể được chi tiêu thông qua ví nóng, sau đó ví nóng có thể chuyển tiếp tiền cho người nhận. Điều này có nghĩa là nếu ví nóng bị xâm phạm, các khoản rút tiền đã đến hạn cũng có thể bị đánh cắp. Điều này cũng có nghĩa là việc ủy ​​quyền một lần rút tiền trở nên phức tạp vì điểm đến cuối cùng của tiền không được bao gồm trong giao dịch rút tiền. Cả OP_VAULT và OP_CCV đều giải quyết vấn đề này (thực tế, chúng sẽ làm cho thiết kế này hoàn toàn lỗi thời).

Sự riêng tư

Các biện pháp kiểm soát tốc độ rút tiền nghiêm ngặt yêu cầu tiền phải được gộp vào một UTXO duy nhất. Điều này đồng nghĩa với việc hy sinh đáng kể quyền riêng tư Chuỗi.

phí xử lý

Lỗi này không phải do bản chất của giao thức mà xuất phát từ thiết kế của bản thử nghiệm này: khóa nóng được liên kết với khóa ví nóng. Do đó, kẻ tấn công có thể rút hết tiền trong ví nóng của bạn trước, ngăn bạn thanh toán phí để xác nhận các giao dịch đòi lại/khôi phục.

Vấn đề này có thể được giảm thiểu bằng cách đảm bảo rằng tháp canh sử dụng một khóa khác và bằng cách phân bổ các khoản tiền riêng để thanh toán phí giao dịch khôi phục, bất kể dịch vụ tháp canh được người dùng hay bên thứ ba vận hành.

Tổng quan về thỏa thuận

Các điều khoản chi tiết của thỏa thuận vẫn đang được soạn thảo.

Vault là một DAG (Đồ thị có hướng không chu trình) quy mô lớn bao gồm các giao dịch đã được tính toán trước; các chuyển đổi giữa các giao dịch này được thực thi bằng cách sử dụng OP_CHECKTEMPLATEVERIFY . Vault được cấu hình với các tham số sau:

• scale : Số tiền rút cơ bản và số tiền rút tăng dần. Mỗi thao tác trên két sắt là một bội số của số tiền này.
• delay : Số lượng khối bổ sung cần chờ để lấy được mỗi phần tăng thêm.
• max-withdrawal : Số lượng tối đa các mặt hàng có thể rút cùng một lúc.
• max-deposit : Số tiền tối đa có thể gửi vào tài khoản cùng một lúc.
• max-depth : Số lượng thao tác mà két sắt có thể hỗ trợ (độ sâu của DAG).

Các thông số này kiểm soát sự cân bằng giữa bảo mật, sự tiện lợi và chi phí đã được tính toán trước.

lịch sử

Dự án kho lưu trữ này bắt đầu bằng một thử nghiệm: liệu có khả thi để tạo ra một kho lưu trữ thân thiện với người dùng chỉ bằng CTV hay không? Người ta thường cho rằng rằng chỉ riêng CTV là không đủ để xây dựng một kho lưu trữ phản ứng lý tưởng, nhưng CTV thực sự có thể được sử dụng để phát triển các máy trạng thái được tính toán trước. Những cấu trúc này có thể dẫn đến nhiều loại hợp đồng trên Chuỗi, yếu tố hạn chế duy nhất là việc tính toán trước. Về mặt lý thuyết thuần túy, CTV cộng với taproot có thể thể hiện các đồ thị chuyển đổi giao dịch cực kỳ phức tạp nhưng cuối cùng có thể liệt kê được, nhưng điều này chỉ có thể đạt được bằng cách liệt kê đầy đủ mọi trạng thái và chuyển đổi trạng thái có thể. Trên thực tế, điều này trở nên không khả thi về mặt tính toán khi tập hợp tham số vượt quá kích thước bị giới hạn nghiêm ngặt.

Kết quả nghiên cứu của tôi cho thấy phương pháp này khả thi đối với một số lượng nhỏ tham số, nhưng tốc độ tính toán trước nhanh chóng làm giảm trải nghiệm người dùng khi tập hợp tham số mở rộng. Việc lưu vào bộ nhớ đệm là khả thi và nên được triển khai để giảm độ trễ trong các lần chạy tiếp theo, nhưng ngay cả khi đó, quá trình tính toán khởi tạo của két sắt vẫn có thể khá dài. Do đó, hy vọng về một két sắt "gần như không giới hạn", với số lượng tham số nhiều hơn bất kỳ trường hợp sử dụng thực tế nào có thể dự đoán được, dường như đã tan biến. Tuy nhiên, chấp nhận một số hạn chế thực tế (có thể được thông báo rõ ràng cho người dùng), MCCV vẫn cung cấp chức năng hữu ích.

So sánh

Giải pháp này không phải là thiết kế an toàn đầu tiên, cũng không phải là thiết kế đầu tiên sử dụng OP_CHECKTEMPLATEVERIFY . Tuy nhiên, theo hiểu biết của tôi, đây là thiết kế an toàn được công bố rộng rãi đầu tiên kết hợp OP_CHECKTEMPLATEVERIFY và taproot theo cách này.

simple-ctv-vault

Như tên gọi cho thấy, " simple-ctv-vault " hướng đến sự đơn giản tối đa. Nó đã truyền cảm hứng cho việc phát triển MCCV của tôi, vì tôi muốn xem các cấu trúc phức tạp hơn có thể được ứng dụng thực tế như thế nào. Simple-ctv-vault cho phép một UTXO rút tiền về địa chỉ nóng (có độ trễ) hoặc được chuyển về địa chỉ lạnh. Đây vẫn là nguyên tắc cơ bản của MCCV, ngoại trừ việc Simple-ctv-vault chỉ hỗ trợ gửi và rút tiền một lần.

“Kho chứa Bitcoin” của Bryan Bishop

Tôi thực sự ước mình biết đến " Bitcoin Vaults " của Bryan Bishop sớm hơn. Thiết kế này về mặt khái niệm và định hướng tương tự như MCCV. Giống như MCCV, nó cũng chia kho tiền thành nhiều phần dựa trên giá trị, được gọi là "phân mảnh" (shards). Nó hỗ trợ các hoạt động kho tiền bị hạn chế, được thực thi bằng giao dịch được ký trước để hủy private key, hoặc thông qua OP_CHECKTEMPLATEVERIFY , ngoại trừ việc nó được thiết kế trước khi kích hoạt taproot. Nếu không có taproot, việc tăng số lượng đường dẫn chi tiêu sẽ yêu cầu sử dụng một tập lệnh witnessScript lớn hơn (đối với các giao dịch chi tiêu). Bryan đã lựa chọn cẩn thận các đường dẫn chi tiêu để kho tiền có thể: chuyển tiền vào kho lưu trữ lạnh; chia kho tiền thành nhiều phần; rút trong đó phần, để lại phần còn lại trong kho tiền. Điểm cuối cùng này đặc biệt giống với MCCV. Trực giác hiện tại của tôi là khả năng của taproot trong việc thể hiện hiệu quả các điều kiện chi tiêu thay thế làm giảm đáng kể nhu cầu chia kho tiền thành nhiều phần. Sử dụng MCCV, người dùng có thể rút đủ số tiền cần thiết để đáp ứng nhu cầu của họ, trong khi các kho tiền còn lại bảo vệ số dư còn lại. Hiệu quả của Taproot cũng cho phép MCCV gửi tiền vào các kho tiền hiện có, điều mà giao thức của Bryan không thể làm được, mặc dù điều này phải trả giá bằng việc tính toán trước nhiều trạng thái. Mặc dù thiết kế giao thức MCCV đã được hoàn thiện trước khi tôi biết về công việc của Bryan, nhưng một số yếu tố thiết kế tương tự, chẳng hạn như chia các kho tiền thành nhiều phần và trích xuất số tiền trong quá trình rút tiền, tạo cảm giác như tìm thấy một người cùng chí hướng.

Thiết kế OP_VAULT và OP_CHECKCONTRACTVERIFY

Hy vọng điều này sẽ không gây ra bất kỳ tranh cãi nào liên quan đến các mã lệnh hạn chế; tôi chỉ muốn chỉ ra rằng các mã lệnh này sẽ thay thế phần lớn thiết kế của tôi. Việc sử dụng các mã lệnh này tránh được tất cả các phép tính trước khiến thiết kế an toàn này trở nên phức tạp. Hơn nữa, chúng cho phép rút tiền một bước, nghĩa là người nhận có thể chỉ định điều này trong giao dịch rút tiền. Điều này tạo điều kiện thuận lợi cho việc ủy ​​quyền kỹ lưỡng được thực hiện bởi trạm giám sát và cho phép người nhận trực tiếp lĩnh nhận tiền của họ (mặc dù người nhận sẽ cần thêm thông tin để xử lý các đầu ra này). Tuy nhiên, tôi cho rằng OP_VAULT và OP_CHECKCONTRACTVERIFY ít có khả năng được kích hoạt hơn OP_CHECKTEMPLATEVERIFY , do đó cần phải xem xét một thiết kế chỉ sử dụng CTV.

Yêu cầu phản hồi

Tôi rất mong nhận được phản hồi về những điều sau:

• Thiết kế giao thức tổng thể
• Sự lựa chọn thiết kế này so với một thiết kế đơn giản hơn
• Nhận xét chung về két sắt
• Trải nghiệm người dùng: Đây chỉ là một dự án thử nghiệm, và có một số lỗi trải nghiệm người dùng đã được biết đến, nhưng tất cả các thao tác có thể có của người dùng đều đã sẵn sàng để thử nghiệm. Vui lòng tham gia đóng góp vào hướng dẫn sử dụng.
• Hiệu năng và chi phí được tính toán trước

tóm lại

Mặc dù phương pháp này có lượng lớn nhược điểm, nhưng nó vẫn mang lại những cải tiến đáng kể về bảo mật cho các quỹ được quản lý. Nó cung cấp trải nghiệm người dùng tương đương mà không cần dựa vào OP_VAULT và OP_CCV , đặc biệt nếu có những cải tiến được thực hiện theo các hướng sau.

Công việc trong tương lai

Nhiều dự án khác cũng đang thu hút sự chú ý của tôi, vì vậy đây không phải là cam kết sẽ dành toàn bộ thời gian cho những lĩnh vực đó trong thời gian tới. Tuy nhiên, trong đó một số dự án mà tôi cho rằng đặc biệt thú vị và đáng để tìm hiểu càng sớm càng tốt.

Các công việc tiềm năng trong tương lai bao gồm:

• Phần mềm Watchtower: Tất cả các tính năng cần thiết cho một trạm canh gác đều có sẵn trong công cụ giao diện dòng lệnh này, nhưng chúng chưa được tích hợp vào một tính năng tự động hóa hữu ích.
• Khôi phục được ủy quyền: Cho phép các két an toàn của tháp canh được tin cậy một phần khởi tạo các hoạt động khôi phục bằng cách chỉ ủy quyền khả năng thực hiện việc đó.
• Tính toán kho bộ nhớ đệm: Cải thiện đáng kể khả năng phản hồi của phần mềm sau khi kho bộ nhớ đệm được khởi tạo cho môi trường sản xuất.
• Tối ưu hóa CPU: Có rất nhiều phương pháp tối ưu hóa, và nhiều trong đó rất dễ thực hiện.
• Khái quát hóa: Điều chỉnh các ngăn xếp phần mềm để hỗ trợ các giao thức máy trạng thái CTV khác.
• Tăng tốc GPU: Thiết kế thân thiện với xử lý song song của chiếc két sắt này cũng giúp nó phù hợp với việc tăng tốc bằng GPU.
• Dự kiến ​​điều này sẽ cho phép xác thực dựa trên STARK đối với các thiết bị ký điện tử phần cứng.

Ý tưởng về xác minh STARK rất thú vị. Nó sẽ cho phép phần cứng tiêu dùng mạnh mẽ tạo ra bằng chứng về kho lưu trữ và tính đúng đắn về mặt hình thức của nó, trong khi các thiết bị ký phần cứng bảo mật hơn sẽ sử dụng bằng chứng nhỏ gọn để xác minh tính đúng đắn về mặt hình thức.

(qua)