Tiếp theo bài đăng trên blog gần đây của chúng tôi về hiệu suất của Cardano và lộ trình tối ưu hóa sổ cái , chúng tôi đã chuẩn bị kỹ thuật sâu hơn về kiến trúc của sổ cái EUTXO.
Ở đây, chúng tôi đưa ra một kiến trúc ví dụ và cũng thảo luận về những cải tiến có thể có sẽ thúc đẩy thông lượng giao dịch và giảm thiểu sự chậm trễ trong quá trình xử lý giao dịch.
Mô hình EUTXO của Cardano là cơ sở vững chắc để phát triển tài chính phi tập trung (DeFi) và ứng dụng phi tập trung (DApp) vì nó tạo điều kiện thuận lợi cho việc xử lý giao dịch song song, cho phép khả năng mở rộng cao hơn so với các mô hình dựa trên tài khoản, cũng như cung cấp cài đặt bảo mật nâng cao.
Tuy nhiên, việc sử dụng thiết kế hoặc cơ chế áp dụng cho các hệ thống dựa trên tài khoản thay vì mô hình EUTXO (đặc biệt là khi xây dựng các sàn giao dịch phi tập trung) có thể dẫn đến các vấn đề tranh chấp. Điều này dẫn đến tình trạng khi một giao dịch mới phụ thuộc vào kết quả của một giao dịch trước đó, do đó gây ra sự chậm trễ, đặc biệt nếu có một số lượng lớn giao dịch. Để loại bỏ vấn đề này, các nhà phát triển nên tránh sử dụng kiểu máy trạng thái đơn luồng và các ứng dụng thiết kế đặc biệt có tính đến các thuộc tính EUTXO.
Một kiến trúc được hình thành tốt trông như thế nào?
Mẫu sổ đặt hàng là một trong những cách tiếp cận áp dụng cho phát triển DEX nếu tương thích với logic hợp đồng thông minh. Và hầu hết các kiến trúc giao thức được đánh giá và trình bày trong bài đăng trên blog của SundaeSwap , dựa trên một cách tiếp cận chung, theo đó:
- người dùng khóa tiền trong một tập lệnh trung gian (mà chúng tôi sẽ gọi là tập lệnh yêu cầu ) cùng với mô tả về các đơn đặt hàng đã gửi (ví dụ: mã thông báo hoặc số liệu)
- bên thứ ba (được gọi là người điều phối ) tổng hợp các đơn đặt hàng theo tập lệnh yêu cầu thành một giao dịch duy nhất sao cho:
- các lệnh bị khóa được chi tiêu cùng với UTXO giữ trạng thái toàn cầu của tập lệnh chính (ví dụ: nhóm thanh khoản) được cập nhật
- kết quả của các lệnh đã thực hiện được gửi lại cho người dùng ban đầu
- một UTXO mới giữ trạng thái toàn cầu được cập nhật nằm ở địa chỉ tập lệnh chính
Khi áp dụng mô hình phân lô như vậy, người ta cần lưu ý rằng, bất cứ khi nào N lệnh đặt ở tập lệnh yêu cầu được sử dụng trong một giao dịch duy nhất, thì tập lệnh yêu cầu sẽ được thực hiện N lần khi gửi giao dịch. Hơn nữa, việc kiểm tra giới hạn bộ nhớ (được kích hoạt khi giao dịch được gửi) được thực hiện bằng cách tổng hợp mức tiêu thụ bộ nhớ cho mỗi lần thực thi tập lệnh yêu cầu duy nhất, cho việc thực thi tập lệnh chính và cho bất kỳ tập lệnh MintingPolicy nào cũng có thể được thực thi (tức là theo giao thức thiết kế). Ngoài ra, cùng một ngữ cảnh giao dịch, tỷ lệ với số lượng đơn đặt hàng được chi tiêu, sẽ được chuyển làm đối số cho mỗi lần thực thi tập lệnh.
Mặc dù đây là một cách tiếp cận tốt, nhưng có thể có những cải tiến để làm cho nó tốt hơn nữa.
Một giải pháp tiềm năng để tránh kích hoạt việc thực thi tập lệnh yêu cầu N lần (tức là trong giao dịch tổng hợp) là người dùng thay vào đó gửi trực tiếp đơn đặt hàng đến địa chỉ khóa công khai của chính họ. Tập lệnh yêu cầu chỉ được sử dụng để thông báo về sự hiện diện của các lệnh đang chờ xử lý và để khóa các khoản phí giao dịch mà sau đó người chốt lệnh có thể yêu cầu sau khi đơn đặt hàng đã được xử lý. Sử dụng giải pháp này, người dùng cũng được yêu cầu ký kết giao dịch tổng hợp để cho phép chi tiêu các đơn đặt hàng. Điều quan trọng cần lưu ý là trong trường hợp này, tất cả người dùng trong đợt phải trực tuyến để tham gia. Một kiến trúc đơn giản hóa cho một giải pháp như vậy có thể được tóm tắt như sau:
Gửi đơn đặt hàng :
- Một tập lệnh MintingPolicy cụ thể có thể được sử dụng để đúc mã thông báo ‘đặt hàng’ được gửi đến địa chỉ khóa công khai của người dùng.
- Băm địa chỉ khóa công khai của người dùng, cùng với mô tả đơn đặt hàng và bất kỳ khoản phí giao dịch cần thiết nào, có thể được gửi tới tập lệnh yêu cầu để thông báo đơn đặt hàng.
Xử lý đơn hàng :
- Người phối hợp kiểm tra các UTXO ở địa chỉ tập lệnh yêu cầu để thu thập mã thông báo ‘đặt hàng’ và xây dựng giao dịch tổng hợp, sao cho mã thông báo ‘đặt hàng’ được tập lệnh chính sử dụng để xác thực giao dịch tổng hợp. Lưu ý rằng nếu mã thông báo ‘đặt hàng’ không có tại địa chỉ khóa công khai tương ứng, đơn đặt hàng được coi là vô hiệu.
- Các UTXO nằm trong tập lệnh yêu cầu không được chi tiêu bởi giao dịch tổng hợp. Chúng chỉ được sử dụng để thu thập các UTXO nắm giữ mã thông báo ‘đặt hàng’.
- Người phối hợp thông báo cho những người dùng có liên quan để ký vào giao dịch tổng hợp để gửi.
- MintingPolicy, liên kết với tập lệnh chính, được sử dụng để tạo mã thông báo ‘biên lai’ cho mỗi đơn đặt hàng được xử lý. Mã thông báo ‘biên lai’ này sẽ được sử dụng bởi người giao dịch để yêu cầu phí giao dịch bị khóa theo tập lệnh yêu cầu.
Thu phí giao dịch:
- Batcher có thể sử dụng từng UTXO ở tập lệnh yêu cầu bằng cách cung cấp mã thông báo ‘biên nhận’ tương ứng.
Các điểm chuẩn được thực hiện trên mạng thử nghiệm công cộng cho thấy rằng với kiến trúc đơn giản này, khoảng 25 đến 30 đơn đặt hàng có thể dễ dàng được xử lý trong một giao dịch duy nhất mà không vượt quá giới hạn bộ nhớ 10 triệu đơn vị. Chúng tôi tin rằng một số tối ưu hóa bổ sung vẫn có thể được thực hiện để tăng con số này.
Các nhà phát triển cũng có thể mở rộng kiến trúc này để xem xét các cơ chế phức tạp hơn đảm bảo đặt hàng xác định, hủy đơn đặt hàng của người dùng trong một khung thời gian cụ thể và bảo vệ bổ sung chống lại những kẻ theo dõi độc hại.
Đây chỉ là một ví dụ về cách người ta có thể áp dụng phương pháp tiếp cận cụ thể của EUTXO đối với thiết kế DApp. Chúng tôi đang trong quá trình mở rộng tài liệu của mình và sẽ chia sẻ các ví dụ khác trong quá trình thực hiện. Hiện tại, bạn có thể tìm thấy một số mẫu mã để tránh sử dụng đồng thời nhiều chữ ký tại đây .
Chúng tôi cũng dự đoán rằng cộng đồng phát triển sẽ xác định thêm nhiều mô hình khác và chúng tôi sẽ rất vui khi đưa những mô hình này vào kho của chúng tôi để xây dựng một nhóm tài nguyên cho cộng đồng phát triển Plutus trong những tháng tới.
Cảm ơn John Woods và nhóm đã đóng góp ý kiến và hỗ trợ trong việc chuẩn bị bài đăng trên blog này.
Comments (No)