Chương trình

Vấn đề

1. Xác định trạng thái kết thúc: điều gì làm cho các ứng dụng tiền điện tử "có thể sử dụng được"

2. Tại sao "trừu tượng chuỗi" là một giải pháp cho vấn đề UX phát sinh từ cấu trúc liên kết cơ bản của các blockchain mô-đun

3. Tại sao các ứng dụng tiền điện tử có thể sử dụng phải được xây dựng trên cơ sở hạ tầng trừu tượng chuỗi

Không gian giải pháp

1. Làm thế nào kiến trúc dựa trên ý định sẽ tạo ra sự trừu tượng của chuỗi

2. Hiểu rằng thị trường ý định hoạt động tốt nhất khi mạng lưới người giải quyết vô cùng lớn và cạnh tranh

3. Khởi động mạng giải quyết ý định đòi hỏi onboard thêm các ứng dụng sẽ tạo ra ý định

Đề xuất

1. Tại sao chúng ta cần một tiêu chuẩn ý định chuỗi chéo ưu tiên "UX giải quyết" để phát triển thị trường bộ giải và ý định lên quy mô đủ lớn để đạt được hiệu ứng mạng

Ứng Dụng Crypto Có Thể Sử Dụng Không Thể Được Xây Dựng Mà Không Có Sự Trừu Tượng Hóa Chuỗi

Có phải những người giỏi nhất và sáng dạ đang xây dựng cơ sở hạ tầng dư thừa không?

Nhiều người đã than thở rằng những kỹ sư crypto giỏi nhất và những người tư duy dựa nhiều vào việc cung cấp thêm không gian khối cho người dùng cuối cùng. Lời phê bình này có ý nghĩa; có quá nhiều L2 có sẵn cho người dùng cuối cùng so với nhu cầu của họ.

Tuy nhiên, tôi bác bỏ quan điểm cho rằng không có bất kỳ ứng dụng tiền ảo hữu ích nào tồn tại.

Tài chính phi tập trung cung cấp cho cá nhân khả năng tự lưu trữ tài sản kỹ thuật số, cho phép họ hoạt động xung quanh các nhà cung cấp dịch vụ nghiêm ngặt và sử dụng tài sản kỹ thuật số của họ để mua những thứ có giá trị trong thế giới thực. Lời hứa về dữ liệu tự lưu trữ cũng cung cấp một lựa chọn ước mơ cho những người cá nhân đang ngày càng hoài nghi về việc tin cậy vào các đế chế FAANG để bảo vệ dữ liệu của họ.

Vấn đề thực sự theo ý kiến của tôi không phải là thiếu ứng dụng tiền điện tử hữu ích mà là sự ma sát cho người dùng cuối cố gắng truy cập chúng. Người dùng cuối cần có thể trải nghiệm các điều sau khi tương tác với các ứng dụng tiền điện tử:

1. Tốc độ: Ứng dụng nên cảm thấy nhanh như các ứng dụng web2.
2. Chi phí: Không giống như web2, tất cả các tương tác web3 phải chịu một số chi phí, nhưng “chi phí mỗi lần nhấp chuột” phải không đáng kể.
3. Khả năng chống kiểm duyệt (không cần xin phép): Bất kỳ ai có ví đều có thể tương tác với ứng dụng nếu họ có đủ khả năng bấm click.
4. Bảo mật: Clicks nên thực hiện những gì người dùng mong đợi và không quay trở lại—tất cả các cập nhật web3 nên là vĩnh viễn.

Đây là các thuộc tính của các ứng dụng crypto “có thể sử dụng”.

Chúng tôi đã cố gắng xây dựng tiền điện tử có thể sử dụng được trong một khoảng thời gian dài

Những giải pháp blockchain tinh chỉnh ngày nay cung cấp cho người tiêu dùng tất cả những tính chất này, nhưng chúng không phải lúc nào cũng có sẵn ở cùng một nơi.

Năm 2020, các chuỗi khối rời rạc, cung cấp hai trong ba thuộc tính cho người dùng cuối: tốc độ, chi phí hoặc bảo mật. Chúng tôi sau đó đã tưởng tượng một tương lai rollup-centric hoặc modularđiều đó sẽ mở khóa đồng thời ba tính chất.

Hôm nay, chúng tôi đã xây dựng nền tảng cho cơ sở hạ tầng trung tâm của Rollup này. L2 cung cấp không gian khối rẻ và nhanh chóng, và hầu hết chúng cung cấp không gian khối không cần phép. Ngược lại, L1 cung cấp không gian khối an toàn, chống lại WW3. (Bạn có thể đọc thêm về sự đánh đổi bảo mật-UX mà L1s và L2s cung cấp trongbài viết khảo sát ngắn của tôi). Các L2 này kết nối một cách an toàn với L1 thông qua các đường dẫn tin nhắn cơ bản, đặt nền móng cho một mạng lưới linh hoạt nhưng có khả năng tương tác. Trong bốn năm qua, chúng tôi đã xây dựng sợi quang giữa các blockchain mà một ngày nào đó sẽ hỗ trợ các ứng dụng tiền điện tử hữu ích. Nhưng tại sao các blockchain modul không thể sử dụng được?

Sự không thể tránh khỏi của mạng lưới blockchain module là tài sản vốn sẽ tích lũy tại các tầng an toàn nhất trong khi lượt nhấp chuột của người dùng sẽ tích lũy tại các tầng nhanh hơn và rẻ hơn.

Mô hình topologija blockchain có tính module khuyến khích việc cung cấp không gian khối an toàn trên một lớp khác với không gian khối rẻ và nhanh. Người dùng sẽ tự nhiên ưa thích lưu trữ giá trị của họ trên các mạng an toàn nhất, nhưng họ sẽ yêu cầu tương tác thường xuyên nhất với các mạng rẻ và nhanh.Theo thiết kế, các đường đi chuẩn giữa L2 và L1 chậm và/hoặc đắt đỏ. Các hiện tượng này giải thích tại sao người dùng phải đi qua những con đường chuẩn này để thanh toán cho các tương tác L2 bằng tài sản L1. Điều này dẫn đến trải nghiệm người dùng crypto 'không thể sử dụng'.

Vitalik về các loại L2 khác nhau

Mục tiêu của sự trừu tượng chuỗi là giảm ma sát khi gửi giá trị qua các đường dẫn trong giao thức này ra xa người dùng.Chain abstractorsgiả sử người dùng thích xác định trạng thái cuối cùng mà họ mong muốn cho các ứng dụng phi tập trung là "ý định" và đó là trách nhiệm của ứng dụng phi tập trung để thực hiện ý định của họ. Người dùng không nên phải hy sinh việc an toàn giữ tài sản của họ để truy cập phí thấp và độ trễ thấp.

Do đó, abstraction mạngphụ thuộc nghiêm trọng vào việc người dùng có thể chuyển giá trị qua các mạng một cách an toàn, rẻ và nhanh chóng. Một luồng người dùng phổ biến ngày nay là người dùng có số dư USDC trên một chuỗi 'an toàn' như Ethereum muốn phát hành một NFT hoặc đổi lấy token mới trên một chuỗi mới hơn như Blast hoặc Base. Cách để thực hiện điều này trong số ít bước nhất có thể là thực hiện tuần tự một loạt giao dịch Bridge→Swap→Mint (hoặc Swap→Bridge→Mint).

Trong ví dụ này, ý định của người dùng là sử dụng USDC của họ trên chuỗi an toàn để tạo ra một NFT trên chuỗi khác. Người dùng sẽ hài lòng miễn là họ nhận được NFT và số dư USDC của họ bị trừ bất cứ nơi nào họ chọn để lưu trữ.

Kiến trúc dựa trên ý định là cách duy nhất để xây dựng trừu tượng chuỗi

Trừu tượng chuỗi phụ thuộc vào chuyển giá trị qua chuỗi, nhưng việc gửi giá trị qua con đường tin nhắn cổ điển entweder đắt đỏ hoặc chậm trễ. "Cầu nhanh" cung cấp lựa chọn rẻ và nhanh chóng cho người dùng gửi giá trị qua mạng lưới, nhưng họ giới thiệu giả định tin cậy mới. Chuyển thông điệp là cách thông minh nhất để xây dựng cầu nhanh bởi vì nó được mô hình hóa dựa trên kiến trúc TCP/IP; nó dựa vào một giao thức cầu hành động như Định tuyến TCP để kết nối hai chuỗi.

Sơ đồ TCP/IP từ ResearchGate

Việc chuyển giá trị thông qua việc truyền thông tin thông qua giao thức cầu nối liên quan đến việc gửi tin nhắn giữa các hợp đồng trên chuỗi nguồn và chuỗi đích. Tin nhắn này được kích hoạt ở phía nguồn bởi một giao dịch của người dùng và được truyền đến phía đích sau khi “độ tin cậy” của tin nhắn được xác minh.

Một tin nhắn chỉ có thể được xác minh sau khi giao dịch chuỗi nguồn khởi tạo tin nhắn đã hoàn tất, có nghĩa là giao dịch đã được bao gồm vĩnh viễn trong chuỗi khối chính thức của chuỗi nguồn. Xác minh này có thể được hoàn thành như một bằng chứng hợp lệ chứng minh sự bao gồm của giao dịch trên chuỗi nguồn, như một đề xuất lạc quan hoặc sau một ngưỡng chữ ký chứng thực đã tích lũy trên mặt nguồn. Khi tin nhắn được chuyển tiếp đến hợp đồng cầu nối trên chuỗi đích, token được phát hành cho người dùng.

Có một số vấn đề cơ bản với kiến trúc này:

1. Cơ chế xác minh phải chờ đợi sự hoàn toàn chắc chắn trước khi gửi tin nhắn đến hợp đồng giao thức chuỗi đích. Điều này có thể mất tới bảy ngày đối với L2 với chu kỳ chắc chắn lạc quan.
2. Một tin nhắn cross-chain được gửi cho mỗi giao dịch cầu hoặc các tin nhắn được gom lại thành một nhóm, nhưng nhóm chỉ có thể được gửi sau khi tin nhắn cuối cùng trong nhóm được hoàn tất.
3. Cầu có khả năng hạn chế trong việc tìm nguồn cung cấp thanh khoản bên ngoài để cải thiện giá cho người dùng vì nó phải là rõ ràng về con đường thực hiện ý định của người dùng.

Các cầu chuyển thông điệp nhanh sẽ không an toàn, chậm, hoặc đắt đỏ tùy thuộc vào cơ chế xác minh. Các chợ mục đích là một kiến trúc thay thế cho cầu chuyển nhanh mà nảy ra từ một sự nhận thức chính:

Giá trị là có thể thay thế và không quan trọng với người nhận cách giá trị được chuyển đi miễn là họ nhận được số tiền

Có thể cầu đường ủy thác việc chuyển giá trị cho một đại lý tinh vi để đạt được tốc độ nhanh hơn và chi phí thấp hơn không? Tính thanh khoản là động trên và ngoại lệ và cải thiện giá có thể được thực hiện nếu cầu đường cơ chế có tính linh hoạt để lựa chọn một lộ trình thực hiện tối ưu vào thời điểm của việc chuyển cầu đường.

Cơ chế ý định cho phép người dùng chỉ định các điều kiện hoặc điều khoản chính xác dưới đây mà giao dịch chuyển giá trị của họ có thể được thực hiện.

Một ý định tối thiểu là một lệnh thanh toán X token từ chuỗi A để nhận Y token trên chuỗi B.

Giao thức cầu không cần gửi một tin nhắn giữa các miền mỗi giao dịch của cầu để thực hiện ý định chuyển miền của người dùng. Thay vào đó, giao thức giao việc chuyển giá trị cho một đại lý được chọn từ mạng giải quyết không cần phép, và đại lý cá nhân sẽ tìm cách đòi tiền lại sau đó từ giao thức cầu. Trái với đó, các cơ chế truyền thông tin xác định rõ cách giao dịch của họ sẽ được thực hiện và không cần phải phụ thuộc vào sự sẵn có của một đại lý.

Giao thức thanh toán ý định

Các giao thức cầu nối dựa trên ý định có thể được gắn nhãn chính xác hơn là các giao thức thanh toán ý định có trách nhiệm đảm bảo rằng người giải quyết không vi phạm các điều kiện được quy định bởi người dùng. Các giao thức thanh toán ý định cung cấp an ninh cho người giải quyết rằng họ sẽ được hoàn trả và được thưởng cho việc thực hiện ý định của người dùng. Để làm điều này, các giao thức thanh toán ý định cần kêu gọi một người tiên tri để xác minh tính xác thực của việc thực hiện ý định. An ninh của người tiên tri có thể dựa trên một giai đoạn thách thức lạc quan, một ngưỡng chứng kiến, hoặc dựa trên chứng minh tính hợp lệ ZK, ví dụ.

Các giao thức thanh toán ý định cung cấp chuyển giá nhanh chóng và rẻ bởi vì các bộ giải cá nhân có thể đảm nhận rủi ro cuối cùng và xác định các con đường thực thi tối ưu

Các cầu nối truyền thông điệp chỉ có thể giao tiếp nhanh chóng khi đạt được sự cuối cùng của chuỗi gốc. Thời gian cuối cùng là bảy ngày đối với các bản tổng hợp lạc quan và một giờ đối với các bản tổng hợp ZK ngày hôm nay. Mặc dù thời gian cuối cùng này sẽ có xu hướng giảm sau khi áp dụng rộng rãi hơn công nghệ máy khách ZK light và những tiến bộ trong công nghệ xác nhận trước trình tự chia sẻ, nhưng không chắc rằng thời gian cuối cùng cho tất cả các blockchain sẽ cảm thấy "ngay lập tức" cho người dùng, cho thấy nhu cầu liên tục về các giải pháp bắc cầu nhanh. Không thể chuyển tiếp một thông điệp nhanh hơn giai đoạn cuối cùng mà không giả định rủi ro cuối cùng — nằm ngoài phạm vi của cầu nối truyền tin nhắn — trừ khi cầu nối muốn thêm một tác nhân đáng tin cậy bổ sung vào đường dẫn chuyển tiếp, người sẽ hỗ trợ tổn thất do tổ chức lại chuỗi.

Tốc độ tăng lên do kiến trúc dựa trên ý định nảy sinh vì các bộ giải quyết cá nhân trong mạng lưới bộ giải quyết không đồng nhất có thể chịu nhiều rủi ro về tính cuối cùng hơn là một giao thức truyền thông qua tin nhắn và thực hiện ý định của người dùng trước khi rủi ro về việc reorg chuỗi hoàn toàn biến mất. Sau đó, các bộ giải quyết sẽ tính phí cho người dùng cho rủi ro cuối cùng mà họ chịu đổi lại là thời gian thực hiện nhanh hơn.

Việc outsourcing việc hoàn thành ý định chéo chuỗi cho một đại lý cũng dẫn đến cải thiện giá trung bình cho người dùng. Trong cầu nối dựa trên ý định, những người giải quyết viên đứng trước các đơn đặt hàng của người dùng trên chuỗi đích mong muốn sẽ được trả lại sau đó bởi hệ thống sau khi việc hoàn thành của họ được xác nhận. Những việc giải quyết ý định này có thể được gom chung lại để phân chia chi phí. Fillers, khác với người dùng, không đòi hỏi thanh toán ngay lập tức và sẽ tính phí cho người dùng tương ứng cho việc giải quyết vốn cho họ. Việc giải quyết thông qua lô không phải là duy nhất đối với kiến trúc dựa trên ý định, nhưng kiến trúc này phối hợp tốt hơn với việc giải quyết qua lô vì nó tách bước thanh toán ra khỏi bước hoàn thành ý định.

Nguồn cải thiện giá lớn hơn đến từ trực giác rằng giá trị có thể thay thế, và việc tìm ra con đường tốt nhất ngay lúc đó thường sẽ vượt trội so với việc chuyển giá trị. (Tuy nhiên, một số con đường sẽ không thể vượt qua về chi phí ngay lúc đó, như khi cầu nối USDC qua CCTP.)

Cầu nối truyền thông phải mã hóa cách họ sẽ chuyển giá trị cho người dùng. Một số người chọn gửi token ra khỏi hồ chứa thanh khoản với tỷ lệ trao đổi xác định trước, trong khi người khác tạo representative tokens cho người nhận, người nhận sau đó cần phải đổi lấy tài sản token theo đúng mong muốn.

Khi thực hiện ý định của người dùng, một tác nhân có thể tìm nguồn cung cấp thanh khoản từ sự kết hợp của các điểm cung cấp thanh khoản trên chuỗi và ngoài chuỗi. Các mạng giải quyết cạnh tranh cung cấp cho người dùng các nguồn thanh khoản không giới hạn trong lý thuyết (nhưng thậm chí các nguồn thanh khoản này cũng có thể bị cạn kiệt nhanh chóng khi khối lượng phát triển theo một hướng trong sự biến động cao trong sự kiện trên chuỗi phổ biến như việc phát hành NFT phổ biến, airdrop và rug pull).

Gửi đơn đặt hàng chuỗi chéo dưới dạng mục đích cho phép người giải nội bộ hóa MEV được tạo của đơn đặt hàng dưới dạng cải thiện giá.

Kiến trúc dựa trên ý định được thiết kế căn bản để đảm bảo an toàn

Các cầu nối dựa trên ý định có thể được xây dựng một cách an toàn vì chúng phân tách các yêu cầu cấp bách của người dùng khỏi các yêu cầu phức tạp của mạng lưới thanh toán. Những người giải quyết có thể chờ đợi thanh toán, khác với người dùng, và họ sẽ tính phí cho người dùng dựa trên thời gian mà giao thức thanh toán làm họ chờ đợi thanh toán. Do đó, các thanh toán dựa trên ý định có thể được xác minh bằng cách sử dụng các cơ chế rất mạnh mẽ mà không có ràng buộc về thời gian chặt chẽ. Điều này được ưa chuộng từ quan điểm bảo mật vì việc xác minh việc thực hiện ý định là phức tạp theo cách trực giác.

Là một ví dụ về xác minh ý định trong quá trình sản xuất, Toàn bộxác minh và hoàn trả các bộ lọc theo lô sau một thời gian thách thức lạc quan 90 phút. Tất nhiên, các mạng thanh toán nên cố gắng hoàn trả các bộ lọc càng nhanh càng tốt để giảm phí người dùng cuối. Một cải tiến trên cơ chế thách thức lạc quan sẽ là một cơ chế chứng minh tính hợp lệ ZK, đòi hỏi mã hóa logic xác minh ý định vào một mạch ZK. Theo ý kiến của tôi, không thể tránh khỏi việc các cơ chế chứng minh tính hợp lệ sẽ thay thế cơ chế thách thức lạc quan và cho phép các mạng thanh toán ý định hoàn trả người dùng nhanh hơn.

Vậy, sự trừu tượng chuỗi ra đời từ kiến trúc dựa trên ý định như thế nào?

Hãy nhớ lại rằng sự trừu tượng hóa chuỗi đòi hỏi phải chuyển giao giá trị chuỗi chéo nhanh chóng và rẻ tiền. Nó cũng không nên yêu cầu người dùng gửi giao dịch onchain trên mạng nơi tài sản của họ được lưu trữ.

Không cần thiết phải được người dùng gửi trên chuỗi nếu nó bao gồm mộtPermit2hoặcEIP3074Chữ ký. Điều này đúng đối với cả cầu nối truyền thông tin và cầu nối dựa trên ý định. Cả hai kiến trúc đều có thể tận dụng mẫu Permit2 để cho phép người dùng ký ngoại chuỗi số lượng token mà họ sẵn lòng trả từ ví chuỗi nguồn của họ.

Thị trường ý định hỗ trợ tốt nhất việc trừu tượng hóa chuỗi vì chúng cung cấp chuyển giá trị chuỗi chéo rẻ và nhanh chóng. Hãy tưởng tượng một thế giới nơi người dùng có thể yêu cầu người giải cung cấp cho họ báo giá để tham gia vào vị thế đặt cọc WETH trên Arbitrum, sử dụng USDC của họ trên Optimism làm khoản thanh toán. Người dùng có thể gửi outchain intent này đến một cuộc đấu giá RFQ, nơi người giải có thể đặt giá thầu cho nó. Người chiến thắng trong cuộc đấu giá sau đó có thể nhận được ý định đã ký của người dùng, bao gồm một khoản trợ cấp để chi tiêu USDC của họ cho Optimism, số lượng WETH mong muốn của họ để nhận được trên Arbitrum và calldata cần thiết để gửi WETH này vào vị trí đặt cọc trên Arbitrum. Người giải sau đó có thể gửi giao dịch này trên Optimism (thay mặt cho người dùng) để bắt đầu ý định chuỗi chéo và kéo USDC từ ví Optimism của người dùng. Cuối cùng, bộ giải có thể điền ý định của người dùng vào Arbitrum bằng cách gửi cho họ WETH và chuyển tiếp calldata để nhập người dùng vào vị trí đặt cọc onchain.

Xây dựng cơ sở hạ tầng trừu tượng chuỗi có nghĩa là làm cho quy trình người dùng này cảm thấy tức thì và rẻ mà không cần họ phải gửi giao dịch trên chuỗi. Hãy kết luận bài viết này bằng cách thảo luận về các rào cản đối với việc áp dụng rộng rãi của ý định.

Kiến trúc Ý định bởi Across

Để trải nghiệm người dùng tốt nhất có thể thực hiện được từ sự trừu tượng chuỗi dựa trên ý định, chúng ta cần một mạng lưới cạnh tranh của người giải quyết

Bridging with intents depends on solver network effects to perform better than message-passing variants. This is the core tradeoff of intent versus message-passing architectures. Realistically, not all applications producing intents will need access to a perfectly competitive set of solvers, and some might prefer routing their intents to mạng lưới giải quyết oligopolisticTuy nhiên, tình trạng hiện tại của mạng lưới giải mã viênnon trưởng thành và không gần như thực hiện được các giả định về sự sống còn của mạng lưới giải quyết viên mà các thị trường ý định phụ thuộc vào.

Chúng tôi không muốn một thế giới nơi mỗi ứng dụng phân tuyến ý định đến các mạng giải quyết cô lập. Trường hợp tốt nhất cho UX là nhiều ứng dụng giao tiếp với cùng các bể giải quyết, và tất cả các ứng dụng đều có tự do thay đổi bể giải quyết họ gửi ý định tới.

Làm thế nào để khởi động mạng giải quyết viên?

Chúng ta phải ưu tiên trải nghiệm người dùng của bộ giải quyết.

Việc chạy một bộ giải quyết ý định là phức tạp và đòi hỏi chuyên môn trong việc xây dựng phần mềm hoạt động hiệu quả cao cũng như quản lý rủi ro hàng tồn khoa học. Tự nhiên, sẽ có một số bên hạn chế quan tâm đến việc trả chi phí khởi nghiệp để chạy mã này. Trong trường hợp tốt nhất, một bộ giải quyết viết cho một ứng dụng phân cấp, giống như một bộ giải quyết UniswapX, có thể được tái sử dụng để giải quyết cho các ứng dụng khác tạo ra ý định như Across và CowSwap.

Chúng ta thực sự cần tăng cường hiệu quả vốn tổng hợp của mạng lưới giải quyết cho tất cả các ứng dụng dựa trên ý định. Điều này sẽ đòi hỏi giải quyết các rào cản đối với việc chạy một bộ giải quyết.

Đối với điều này, chúng ta cần các ứng dụng phi tập trung tạo ra ý định để được nhìn thấy bởi bất kỳ người giải quyết nào và đảm bảo tất cả người giải quyết đều có quyền truy cập vào nhiều mạng lưới thanh toán ý định khác nhau và cạnh tranh. Điều này sẽ mang lại niềm tin cho người giải quyết rằng họ có thể chọn định tuyến các hoàn tất ý định của mình đến một mạng lưới thanh toán mà họ tin tưởng. Sự cạnh tranh giữa các mạng lưới thanh toán cũng sẽ giảm chi phí cho người giải quyết.

Mệnh đề giá trị của các mạng giải quyết ý định là cung cấp an ninh cho người giải quyết cũng như các tính năng khác có thể ảnh hưởng đến khả năng của người giải quyết để thực hiện một ý định.

Lựa chọn mạng giải quyết ý định của người giải quyết sẽ ảnh hưởng đến khả năng họ cung cấp phí và cam kết thời gian thực hiện cho người dùng. Một số mạng giải quyết có thể cung cấp khoảng thời gian độc quyền cho người giải quyết, điều này sẽ hỗ trợ việc phát triển các cuộc đấu giá ngoại xích nơi mà người giải quyết và người dùng có thể đàm phán và cam kết đối với phí relay. (Những cuộc đấu giá ý định này cũng có thể cung cấp các sự xác nhận trước kinh tế được kết nối, từ đó nâng cao trải nghiệm người dùng. Để tìm hiểu thêm về quy trình người dùng có chức năng khám phá ý định thông qua các cuộc đấu giá và xác nhận trước, tôi khuyên bạn nên xem talk by Karthik của Sorella.)

Một số mạng lưới thanh toán có thể cung cấp sự hết hạn của ý định (tức là, trả lại giá trị cho người dùng sau khi hạn chót hoàn tất đã qua), hỗ trợ lại ý định (tức là, mạng lưới thanh toán sử dụng tờ bảng cân đối của chính mình để thực hiện ý định của người dùng nếu không có bộ giải nào), hoặc chuỗi thanh toán linh hoạt (tức là, cho phép bộ giải được trả lại trên chuỗi mà họ lựa chọn).

Cuối cùng, các mạng thanh toán sẽ cạnh tranh gay gắt để trả tiền cho người giải quyết nhanh chóng và giá rẻ mà không đ compromising on security. Ngược lại, người giải quyết sẽ gửi luồng đơn hàng của họ đến các mạng thanh toán cho phép họ cung cấp các khoản phí rẻ nhất cho người dùng để họ có thể chiến thắng luồng đơn hàng dapp. Sự cạnh tranh trong các mạng thanh toán và người giải quyết phụ thuộc vào tất cả các bên trong chuỗi cung ứng cố gắng hòa nhịp để nói cùng một ngôn ngữ, và sự cạnh tranh sẽ dẫn đến trải nghiệm người dùng tốt nhất cho việc chuyển giá trị qua các chuỗi.

Rõ ràng là chúng ta cần một tiêu chuẩn cho ý định liên chuỗi

Nếu các trình giải có thể giả định rằng ý định sẽ chia sẻ các yếu tố chung, sau đó họ có thể tái sử dụng mã của họ để giải quyết các ý định được tạo ra bởi các ứng dụng phiên bản khác nhau và sau đó giảm chi phí thiết lập của họ. Nếu các ứng dụng phiên bản khác nhau tạo ra các ý định tuân thủ theo cùng một tiêu chuẩn, sau đó họ có thể chuyển hướng tất cả các ý định của họ đến cùng một bể trình giải. Điều này sẽ giúp đưa thế hệ tiếp theo của các ứng dụng phiên bản khác nhau vào hệ thống bằng cách cho họ khả năng cắm các ý định qua chuỗi trực tiếp vào một bể trình giải hiện có và trưởng thành. Các ứng dụng mới sẽ không cần phải đưa từng trình giải vào hệ thống và, thay vào đó, sẽ có quyền truy cập vào các chuyển giá trị rẻ, nhanh, an toàn và không cần phép.

Phần mềm theo dõi bên thứ ba cũng sẽ dễ dàng theo dõi trạng thái ý định cho bất kỳ ứng dụng mới nào nếu chúng tuân theo một tiêu chuẩn.

Tiêu chuẩn này nên cho phép bên chủ thể hoặc người giải quyết xác định mạng lưới thanh toán mà họ muốn thanh toán ý định của mình trên đó.

Tôi tưởng tượng các giao thức thanh toán cạnh tranh như SUAVE, Across, Anoma và Khalani cung cấp các tính năng khác nhau cho người giải quyết ý định. Tùy thuộc vào mạng thanh toán nào đang trả tiền cho người giải quyết, người giải quyết có thể đưa ra các cam kết về giá và thời gian khác nhau cho chủ sở hữu của ý định. Ứng dụng phi tập trung và người giải quyết có thể đồng ý đưa ý định của người dùng đến một mạng thanh toán họ tin tưởng để tránh sự kiểm duyệt, duy trì quyền riêng tư dữ liệu và cũng đủ an toàn để được tin tưởng trả tiền cho người giải quyết.

Bằng cách bắt buộc lựa chọn mạng giải quyết vào chính đơn hàng ý định, người giải quyết có thể nhúng sự chắc chắn này vào bảng giá mà họ sẽ hiển thị cho người dùng. Người giải quyết và người dùng sẽ loại bỏ sự không chắc chắn ban đầu về giá cầu truyền trước khi gửi ý định lên chuỗi, giảm chi phí.

Hợp tác với Uniswap và dựa trên phản hồi từ nhóm làm việc CAKE, Across và tôi đề xuất tiêu chuẩn ý định xuyên chuỗi sau ưu tiên UX của bộ giải đấu.

/// @titleLoại Đơn Đặt Hàng CrossChain

/// @noticeCấu trúc lệnh tiêu chuẩn để được ký bởi người trao đổi, phổ biến cho người điền và nộp cho hợp đồng thanh toán

struct CrossChainOrder {

/// @dev Địa chỉ hợp đồng mà lệnh được dành để giải quyết bởi./// Người gửi gửi lệnh này đến địa chỉ hợp đồng này trên chuỗi nguồnđịa chỉ settlementContract;/// @dev Địa chỉ của người dùng khởi động việc trao đổi,/// các mã thông báo đầu vào của họ sẽ được lấy và giữ địa chỉ swapper;/// @dev Số lần sử dụng để bảo vệ khỏi việc lặp lại cho lệnhuint256 nonce;/// @dev ChainId của chuỗi nguồnuint32 originChainId;/// @dev Dấu thời gian mà lệnh phải bắt đầuuint32 initiateDeadline;/// @dev Dấu thời gian mà lệnh phải được điền vào chuỗi đíchuint32 fillDeadline;/// @dev Dữ liệu cụ thể theo triển khai/// Có thể được sử dụng để xác định mã thông báo, số lượng, chuỗi đích, phí, tham số giải quyết,/// hoặc bất kỳ thông tin cụ thể nào khác của loại lệnhbytes orderData;

}

Tiêu chuẩn này được thiết kế để làm cho công việc của người giải dễ dàng hơn. Một lựa chọn cố chấp mà nó đưa ra là hỗ trợ Permit2 / EIP3074 nguyên bản với nonce và initiateDeadline và nó cung cấp cho người điền một số đảm bảo, chẳng hạn như số tiền họ sẽ được hoàn trả từ mạng thanh toán và định dạng ý định của người dùng mà họ có thể theo dõi. Hơn nữa, một hàm khởi tạo được định nghĩa trong tiêu chuẩn quan trọng cho phép filler, người sẽ mang đơn đặt hàng onchain, chỉ định onchain "fillerData" bổ sung mà người dùng sẽ không biết tại thời điểm họ ký CrossChainOrder. Điều này cho phép người điền đảm bảo rằng họ được thưởng bằng hợp đồng thanh toán để gửi giao dịch meta của người dùng và cũng đặt thông tin cụ thể về trả nợ như chuỗi trả nợ.

Tiêu chuẩn này cũng được thiết kế để giúp cho các ứng dụng phi tập trung dễ dàng theo dõi trạng thái hoàn thành ý định trong suốt vòng đời của nó. Bất kỳ hợp đồng thanh toán nào triển khai tiêu chuẩn này nên tạo ra một loại con tùy chỉnh ResolvedCrossChainOrder có thể được phân tích từ trường orderData bất kỳ. Điều này có thể bao gồm thông tin như các token tham gia trong việc đổi chỗ, các chuỗi đích, và các ràng buộc hoàn thành khác. Một hàm giải quyết được bao gồm trong tiêu chuẩn để cho phép các ứng dụng phi tập trung hiểu cách hiển thị trạng thái ý định cho người dùng và cho người giải quyết biết cấu trúc đơn đặt hàng chính xác mà họ đang làm việc.

///@titleLoại ResolvedCrossChainOrder đã được giải quyết

/// @noticeMột biểu diễn chung cho việc thực hiện một đơn đặt hàng

///@devXác định tất cả các yêu cầu để điền một đơn hàng bằng cách tách ra dữ liệu đơn hàng cụ thể của việc thực hiện.

///@devNhằm cải thiện tích hợp tổng quát bằng cách cho phép các bộ lọc tính toán thông tin đầu vào và đầu ra chính xác của bất kỳ thứ tự nào

cấu trúc ResolvedCrossChainOrder {

/// @dev Địa chỉ hợp đồng mà đơn hàng định được giải quyết bởi.address settlementContract;/// @dev Địa chỉ của người dùng khởi động giao dịch đổi địa chỉ swapper;/// @dev Số thứ tự được sử dụng như bảo vệ chống lại việc lặp đơn hànguint256 nonce;/// @dev ChainId của chuỗi nguồnuint32 originChainId;/// @dev Thời gian mà đơn hàng phải được khởi tạouint32 initiateDeadline;/// @dev Thời gian mà đơn hàng phải được thực hiện trên chuỗi( các) đíchuint32 fillDeadline;/// @dev Các đầu vào mà người sử dụng phải cung cấp như một phần của việc khởi tạo đơn hàngInput[] swapperInputs;/// @dev Các đầu ra mà người sử dụng sẽ nhận được như một phần của việc thực hiện đơn hàngOutput[] swapperOutputs;/// @dev Các đầu ra mà người điền sẽ nhận được như một phần của việc giải quyết đơn hàngOutput[] fillerOutputs;

}

/// @noticeTokens được gửi bởi người hoán đổi như là đầu vào cho lệnh

struct Đầu vào {

/// @dev Địa chỉ của mã token ERC20 trên chuỗi nguồn địa chỉ token;/// @dev Số lượng token cần gửiuint256 số lượng;

}

///@noticeTokens phải nhận được để hoàn thành đơn hàng hợp lệ

struct Output {

/// @dev Địa chỉ của token ERC20 trên chuỗi đích/// @dev địa chỉ (0) được sử dụng như một báo hiệu cho token bản địađịa chỉ token;/// @dev Số lượng token cần gửiuint256 số lượng;/// @dev Địa chỉ để nhận các token đầu rađịa chỉ người nhận;/// @dev Chuỗi đích cho đầu ra nàyuint32 chainId;

}

Một triển khai hợp lệ của hợp đồng thanh toán PHẢI triển khai giao diện ISettlementContract:

/// @titleISettlementContract

/// @noticeGiao diện tiêu chuẩn cho hợp đồng thanh toán

interface ISettlementContract {

/// @notice Khởi động quá trình thanh toán của một đơn đặt hàng qua chuỗi/// @dev Được gọi bởi người điền/// @param order Định nghĩa CrossChainOrder/// @param signature Chữ ký của người hoán đổi trên đơn đặt hàng/// @param fillerData Bất kỳ dữ liệu do người điền xác định cần thiết bởi người giải quyết hàm khởi động(CrossChainOrder order, bytes signature, bytes fillerData) ngoại;/// @notice Giải quyết một đơn đặt hàng qua chuỗi cụ thể thành một ResolvedCrossChainOrder chung/// @dev Được thiết kế để cải thiện tích hợp chuẩn hóa của các loại đơn đặt hàng và hợp đồng thanh toán khác nhau/// @param order Định nghĩa CrossChainOrder/// @param fillerData Bất kỳ dữ liệu do người điền xác định cần thiết bởi người giải quyết/// @returns ResolvedCrossChainOrder dữ liệu đơn đặt hàng được cung cấp bao gồm các đầu vào và đầu ra của đơn đặt hàng hàm giải quyết(CrossChainOrder order, bytes fillerData) ngoại xem trước trả về (ResolvedCrossChainOrder);

}

Mục tiêu thiết kế của tiêu chuẩn này là tăng cường trải nghiệm người giải quyết, làm cho họ dễ dàng hơn trong việc hỗ trợ nhiều mạng giải quyết, và tính toán xác định phần thưởng của họ. Tôi tin rằng điều này sẽ cho họ khả năng đưa ra báo giá chính xác và chặt chẽ hơn cho người dùng. Bạn có thể đọc thêm chi tiết về tiêu chuẩn này, mã tên ERC7683,trong bài đăng X/Twitter nàyvà cuộc thảo luận xoay quanh nótrên diễn đàn Ethereum Magicians.

Closing Thoughts

“Intentions” are confusing because they are not defined, and this lack of a definition is creating real UX defects.

Mọi người đều muốn người khác sử dụng định nghĩa chuẩn của họ về một ý định, vì vậy tôi hoàn toàn công nhận rằng việc thiết lập các tiêu chuẩn là gần như không thể. Tôi không nghĩ rằng việc xác định một hệ thống thanh toán ý định trước và cố gắng thu hút lưu lượng đặt hàng sau là cách tiếp cận đúng để thiết lập một tiêu chuẩn trên toàn ngành công nghiệp.

Theo ý kiến của tôi, cách tiếp cận linh hoạt hơn là cho các ứng dụng phi tập trung (dapps) đã sở hữu rất nhiều luồng người dùng và phát sinh nhiều ý định người dùng sẽ đồng ý tuân thủ một số tiêu chuẩn tối thiểu mà các bộ giải quyết hiện tại của họ sẽ áp dụng. Điều này sẽ tạo ra một bể giải quyết mới và lớn hơn. Bằng cách tiếp cận luồng đơn hàng hợp nhất từ những nơi uy tín hiện tại, bể giải quyết mới này sẽ kiếm được nhiều lợi nhuận hơn và có thể đưa ra giá tốt hơn cho người dùng cuối cùng. Cuối cùng, các ứng dụng phi tập trung mới cũng sẽ yêu cầu định tuyến ý định của họ đến bể giải quyết này và sẽ hỗ trợ tiêu chuẩn ý định của nó.

Để khởi đầu, Across và Uniswap đồng đề xuất một tiêu chuẩnđối với tất cả các bên liên quan đến chuỗi cung ứng sử dụng khi xử lý đơn đặt hàng của người dùng để gửi X token từ chuỗi A và nhận Y token trên chuỗi B. Luồng đơn hàng chạy qua UniswapX (có lợi thế so sánh trong thiết kế đấu giá và nguồn gốc ý định) và Across (có lợi thế so sánh trong việc giải quyết ý định hoàn thành) có thể hợp nhất và bắt đầu quá trình nuôi dưỡng mạng lưới giải quyết viên cạnh tranh, lớn hơn.

Disclaimer：

1. Bài viết này được sao chép từ [GateGương ], Tất cả quyền bản quyền thuộc về tác giả gốc [GateNick Pai]. Nếu có bất kỳ ý kiến phản đối nào về việc tái in này, vui lòng liên hệ với Gate Learnđội của họ sẽ xử lý ngay lập tức.
2. Liability Disclaimer: Quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không hình thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.