Blockchain mô-đun: Theo dõi thực thi, dữ liệu và thanh toán
Một blockchain mô-đun phân chia trách nhiệm giữa các thành phần thay vì yêu cầu một hệ thống thực hiện mọi nhiệm vụ. Điều đó có thể làm cho việc mô tả mạng nghe có vẻ đơn giản: việc thực thi xảy ra ở đây, dữ liệu ở đó và việc giải quyết xảy ra ở nơi khác. Câu hỏi quan trọng là mỗi thành phần thực sự đảm bảo điều gì.
Bài viết này so sánh các vai trò kiến trúc chứ không phải giá token hay thứ hạng của các dự án. Thiết kế mô-đun không tự động ngụ ý rủi ro thấp hơn, lợi nhuận đầu tư cao hơn hoặc bảo mật giống hệt nhau trong quá trình triển khai.
Tách biệt các công việc trước khi so sánh các hệ thống
Việc thực thi áp dụng các quy tắc giao dịch và tính toán thay đổi trạng thái được đề xuất. Tính sẵn có của dữ liệu liên quan đến việc liệu thông tin cần thiết để xác minh hệ thống đã được cung cấp hay chưa. Lớp thanh toán xác định cách giao thức chấp nhận cam kết mật mã về trạng thái chuỗi (state commitments), bằng chứng hoặc tranh chấp. Sự đồng thuận xác định thứ tự đã thống nhất hoặc lịch sử được chấp nhận trong một hệ thống.
Các vai trò này có thể chồng chéo hoặc được phân bổ theo nhiều cách khác nhau. Nhãn dự án là chưa đủ: mạng có thể tự gọi nó là mô-đun trong khi vẫn duy trì quyền kiểm soát đáng kể trong trình sắp xếp thứ tự, khóa nâng cấp hoặc ủy ban dữ liệu. Vẽ bản đồ phụ thuộc thực tế thay vì giả định rằng tất cả các mạng mô-đun đều có chung một mô hình tin cậy.
Tài liệu về tính sẵn có của dữ liệu của Ethereum giải thích lý do tại sao việc xác minh phụ thuộc vào quyền truy cập vào dữ liệu giao dịch và tại sao các ứng dụng khách và bản tổng hợp nhẹ cần có sự đảm bảo thích hợp. Truy cập dữ liệu là một câu hỏi khác với việc liệu một phép tính được thực hiện có chính xác hay không.
Thực hiện theo một giao dịch giả định
Hãy tưởng tượng một người dùng gửi một giao dịch đến một mạng thực thi. Một trình sắp xếp thứ tự bao gồm nó trong một đợt. Hệ thống cung cấp dữ liệu cần thiết bằng cách sử dụng lớp dữ liệu đã chọn và gửi cam kết trạng thái, với cơ chế xác minh theo yêu cầu của thiết kế, cho lớp thanh toán.
Người dùng có thể thấy xác nhận sớm trước khi mọi giai đoạn đạt đến trạng thái cuối cùng. Ghi lại ý nghĩa của từng trạng thái: đã nhận, được sắp thứ tự, thực thi, dữ liệu được xuất bản, bằng chứng được chấp nhận hoặc cửa sổ tranh chấp đã hoàn tất. Không gắn nhãn xác nhận sớm nhất là thanh toán cuối cùng trừ khi giao thức hỗ trợ việc giải thích đó.
Ví dụ này mô tả các vai trò thay vì quy định một trình tự chung. Các bản tổng hợp và hệ thống mô-đun khác nhau có thể kết hợp các giai đoạn hoặc sử dụng các cách sắp xếp bằng chứng và tính hữu hạn khác nhau.
Hỏi điều gì xảy ra khi một thành phần bị lỗi
Nếu trình sắp xếp thứ tự dừng lại, người dùng có thể gửi giao dịch theo cách khác và với những điều kiện nào? Nếu một dịch vụ dữ liệu giữ lại thông tin thì ai sẽ phát hiện ra thông tin đó và người dùng có thể xác minh điều gì? Nếu lớp thanh toán bị tắc nghẽn, các cam kết hoặc việc rút tiền sẽ bị ảnh hưởng như thế nào?
Trả lời những câu hỏi này từ tài liệu hiện tại, bao gồm các thủ tục khẩn cấp và kiểm soát hành chính. Một phương án dự phòng được mô tả trong lộ trình không nhất thiết phải có hiệu quả. Mạng tiếp tục hiển thị số dư có thể vẫn bị giảm khả năng chấp nhận giao dịch hoặc hoàn tất việc rút tiền.
Xem xét các phần phụ thuộc của cầu nối một cách riêng biệt. Mã thông báo xuất hiện trên hai mạng không có nghĩa là tuyến chuyển kế thừa mọi thuộc tính bảo mật của cả hai chuỗi.
So sánh chi phí hoàn chỉnh và trải nghiệm người dùng
Phí thực hiện thấp chỉ là một phần chi phí giao dịch. Các hoạt động xuất bản, thanh toán, bắc cầu và rút dữ liệu có thể làm tăng thêm phí hoặc sự chậm trễ. So sánh các hành động tương đương trong cùng khoảng thời gian và giải thích ai sẽ trả chi phí nào.
Đo toàn bộ lộ trình phù hợp với người dùng: nhập, thực hiện, xác nhận, rút tiền và quay lại tài sản hoặc mạng mong muốn. Điểm chuẩn chỉ bao gồm một chặng không nên được trình bày dưới dạng giá của toàn bộ chuyến đi khứ hồi. Tiết kiệm chi phí cũng có thể thay đổi tùy theo nhu cầu và điều kiện của lớp dữ liệu.
Sử dụng danh sách kiểm tra phụ thuộc
Đối với mỗi hệ thống, ghi lại các quy tắc thực hiện, thẩm quyền được sắp thứ tự, vị trí dữ liệu, cơ chế xác minh, đích giải quyết, kiểm soát nâng cấp và thủ tục thoát. Đánh dấu những xác nhận quyền sở hữu nào đang tồn tại và những xác nhận quyền sở hữu nào đã được lên kế hoạch. Bao gồm các nguồn và ngày được kiểm tra vì cài đặt kiến trúc có thể thay đổi.
Đối với một vấn đề có liên quan nhưng khác biệt, hãy đọc so sánh thông báo chuỗi chéo: nó tuân theo hướng dẫn giữa các chuỗi, trong khi hướng dẫn này tuân theo sự phân chia công việc bên trong một kiến trúc.
Thiết kế kỹ thuật của giao thức và quyền kinh tế của mã thông báo của nó là những câu hỏi nghiên cứu riêng biệt. Kiểm tra tiện ích mã thông báo và tính sẵn có của thị trường thực tế một cách độc lập thông qua tài liệu chính thức và trang thị trường OrangeX, thay vì coi yêu cầu mở rộng quy mô là kết luận giao dịch.
