Agenda

Masalah

1. Menentukan keadaan akhir: apa yang membuat aplikasi kripto "dapat digunakan"

2. Mengapa "abstraksi rantai" adalah solusi untuk masalah UX yang muncul dari topologi dasar blockchain modular

3. Mengapa aplikasi kripto yang dapat digunakan harus dibangun di atas infrastruktur abstraksi rantai

Ruang Solusi

1. Bagaimana arsitektur berbasis niat akan menimbulkan abstraksi rantai

2. Memahami bahwa pasar niat berkinerja terbaik ketika jaringan pemecah besar dan kompetitif

3. Bootstrap jaringan pemecah maksud memerlukan orientasi lebih banyak aplikasi yang akan menghasilkan maksud

Usulan

1. Mengapa kita memerlukan standar niat lintas-rantai yang mengutamakan “solver UX” untuk mengembangkan pasar solver dan niat ke skala yang cukup besar untuk mencapai efek jaringan

Aplikasi Crypto yang Dapat Digunakan Tidak Dapat Dibangun Tanpa Abstraksi Rantai

Apakah yang terbaik dan paling cerah kita membangun infrastruktur yang berlebihan?

Banyak yang menyesalkan bahwa insinyur crypto terbaik dan sebagian besar pemikir berbasis terlalu mengalokasikan perhatian dan energi untuk menawarkan lebih banyak ruang blok kepada pengguna akhir. Kritik ini memiliki manfaat; ada terlalu banyak L2 yang tersedia untuk pengguna akhir relatif terhadap permintaan untuk mereka.

Namun, saya menolak gagasan bahwa tidak ada aplikasi kripto yang berguna yang ada.

Keuangan terdesentralisasi menawarkan kemampuan kepada individu untuk menyimpan aset digital sendiri, memungkinkan mereka untuk beroperasi di sekitar penyedia layanan yang keras dan menggunakan aset digital mereka untuk membeli barang yang dihargai di dunia nyata. Janji data yang disimpan sendiri juga menawarkan alternatif utopia bagi individu yang semakin waspada terhadap keamanan data FAANG.

Menurut pendapat saya, masalah sebenarnya bukanlah kurangnya aplikasi kripto yang berguna tetapi gesekan bagi pengguna akhir yang mencoba mengaksesnya. Pengguna akhir seharusnya dapat merasakan hal berikut saat berinteraksi dengan aplikasi kripto:

1. Kecepatan: Aplikasi harus terasa secepat aplikasi web2.
2. Biaya: Tidak seperti web2, semua interaksi web3 harus menimbulkan biaya tertentu, tetapi "biaya per klik" harus diabaikan.
3. Ketahanan sensor ('tanpa izin'): Siapa pun yang memiliki dompet seharusnya dapat berinteraksi dengan aplikasi jika mampu untuk mengklik.
4. Keamanan: Klik harus melakukan apa yang pengguna harapkan dan tidak membatalkan—semua pembaruan web3 harus permanen.

Ini adalah properti dari aplikasi kripto yang “dapat digunakan”.

Kami telah mencoba membangun kripto yang dapat digunakan untuk waktu yang lama

Solusi blockchain modular saat ini menawarkan konsumen semua properti ini, tetapi mereka tidak semua tersedia di tempat yang sama.

Pada tahun 2020, blockchain bersifat monolitik, menawarkan dua dari tiga properti kepada pengguna: kecepatan, biaya, atau keamanan. Kami kemudian membayangkan sebuahMasa depan rollup-sentris atau modularyang akan membuka ketiga properti secara bersamaan.

Hari ini, kami telah membangun dasar untuk infrastruktur ini yang berpusat pada rollup. L2 menawarkan ruang blok yang murah dan cepat, dan kebanyakan dari mereka menawarkan ruang blok tanpa izin. Sebaliknya, L1 menawarkan ruang blok yang aman dan tahan terhadap WW3. (Anda dapat membaca lebih lanjut tentang pertukaran keamanan-UX yang ditawarkan oleh L1 dan L2 diartikel survei singkat saya). L2 ini terhubung dengan aman ke L1 melalui jalur pesan kanonik, meletakkan dasar untuk jaringan modular namun dapat dioperasikan. Dalam empat tahun terakhir, kami telah membangun serat optik antara blockchain yang suatu hari nanti akan mendukung aplikasi crypto yang berguna. Tetapi mengapa blockchain modular sangat tidak dapat digunakan?

Ketidakmungkinan jaringan blockchain modular adalah bahwa aset modal akan terakumulasi di lapisan yang paling aman sementara klik pengguna akan terakumulasi di lapisan yang lebih cepat dan lebih murah.

Topologi blockchain modular mendorong ruang blok yang aman ditawarkan pada lapisan yang berbeda daripada ruang blok yang murah dan cepat. Pengguna secara alami akan lebih memilih untuk menyimpan nilai mereka di jaringan yang paling aman, tetapi mereka akan menuntut untuk berinteraksi paling sering dengan yang murah dan cepat.Menurut desain, jalur kanonikal antara L2 dan L1 lambat dan/atau mahal. Fenomena ini menjelaskan mengapa pengguna harus melalui jalur kanonikal ini untuk membayar interaksi L2 menggunakan aset L1. Hal ini mengakibatkan UX kripto yang 'tidak dapat digunakan'.

Vitalik tentang berbagai jenis L2s

Tujuan abstraksi rantai adalah untuk mengurangi gesekan dalam mengirimkan nilai melalui jalur dalam protokol ini dari pengguna.Chain abstractorsasumsikan bahwa pengguna lebih memilih untuk menentukan keadaan akhir yang diinginkan mereka kepada dapps sebagai "niat" dan itu adalah tanggung jawab dari dapp untuk memenuhi niat mereka. Pengguna seharusnya tidak harus mengorbankan penitipan aman aset mereka untuk mengakses biaya rendah dan latensi rendah.

Oleh karena itu, abstraksi rantaibergantung secara kritis pada pengguna dapat mentransfer nilai melintasi jaringan dengan aman, murah, dan cepat. Alur pengguna umum saat ini adalah pengguna dengan saldo USDC pada rantai yang "aman" seperti Ethereum ingin membuat NFT atau menukar token baru pada rantai yang lebih baru seperti Blast atau Base. Cara untuk melakukannya dengan sedikit langkah mungkin adalah dengan secara berurutan menjalankan serangkaian transaksi Jembatan→Tukar→Mint (atau Tukar→Jembatan→Mint).

Dalam contoh ini, niat pengguna adalah untuk menggunakan USDC mereka di rantai yang aman untuk membuat NFT di rantai lain. Pengguna akan puas selama mereka menerima NFT dan saldo USDC mereka didebit di mana pun mereka memilih untuk menyimpannya.

Arsitektur Berbasis Tujuan adalah Satu-satunya Cara untuk Membangun Abstraksi Rantai

Abstraksi rantai bergantung pada transfer nilai lintas-rantai, tetapi mengirim nilai melalui jalur pesan kanonikal either mahal atau lambat. “Jembatan cepat” menawarkan alternatif murah dan cepat bagi pengguna untuk mengirim nilai lintas jaringan, tetapi mereka memperkenalkan asumsi kepercayaan baru. Perpindahan pesan adalah cara paling intuitif untuk membangun jembatan cepat karena dimodelkan dari arsitektur TCP/IP; ini bergantung pada protokol jembatan yang bertindak sebagai Router TCP untuk menghubungkan dua rantai.

Diagram TCP/IP dari ResearchGate

Transfer nilai melalui pengiriman pesan melibatkan protokol jembatan mengirim pesan antara kontrak-kontraknya di rantai asal dan tujuan. Pesan ini dipicu di sisi asal oleh transaksi pengguna dan diteruskan ke sisi tujuan setelah "keberhasilan" pesan tersebut diverifikasi.

Pesan hanya dapat diverifikasi setelah transaksi rantai asal yang memulai pesan telah selesai, yang berarti transaksi tersebut secara permanen termasuk dalam blockchain kanonik rantai asal. Verifikasi ini dapat diselesaikan sebagai bukti validitas yang membuktikan penyertaan konsensus transaksi pada rantai asal, sebagai proposal optimis, atau setelah ambang batas tanda tangan saksi yang membuktikan penyertaannya telah terakumulasi di sisi asal. Setelah pesan diteruskan ke kontrak jembatan pada rantai tujuan, token dilepaskan ke pengguna.

Ada beberapa masalah mendasar dengan arsitektur ini:

1. Mekanisme verifikasi harus menunggu kesempurnaan penuh sebelum mengirim pesan ke kontrak protokol rantai tujuan. Ini bisa memakan waktu hingga tujuh hari untuk L2 dengan periode kesempurnaan yang optimis.
2. Satu pesan lintas rantai dikirim per transaksi jembatan ATAU pesan-pesan dikelompokkan bersama, tetapi kelompok hanya dapat dikirim setelah pesan terakhir dalam kelompok tersebut difinalisasi.
3. Jembatan memiliki kemampuan terbatas untuk mencari likuiditas eksternal untuk memberikan peningkatan harga kepada pengguna karena harus bersifat deklaratif tentang jalur pemenuhan niat pengguna.

Jembatan cepat penyampaian pesan akan menjadi tidak aman, lambat, atau mahal tergantung pada mekanisme verifikasi. Pasar niat adalah arsitektur alternatif untuk menjembatani cepat yang muncul dari wawasan utama:

Nilai itu dapat dipindahtangankan dan seharusnya tidak masalah bagi penerima bagaimana nilai tersebut ditransfer asalkan mereka menerima dana

Dapatkah sebuah jembatan mengalihkan transfer nilai ke agen yang canggih untuk mendapatkan kecepatan dan biaya yang lebih rendah? Likuiditas dinamis di dalam dan di luar rantai dan peningkatan harga dapat diwujudkan jika mekanisme jembatan memiliki fleksibilitas untuk memilih jalur eksekusi yang optimal pada saat transfer jembatan.

Mekanisme niat memungkinkan pengguna untuk menentukan kondisi atau perjanjian yang tepat di bawah mana transaksi transfer nilai mereka dapat dieksekusi.

Sebuah niat yang dapat dijalankan minimal adalah pesanan untuk membayar token X dari rantai A untuk menerima token Y di rantai B.

Protokol jembatan tidak perlu mengirim pesan antar domain per transaksi jembatan untuk memenuhi tujuan lintas domain pengguna. Sebaliknya, protokol mengoutsourcing transfer nilai ke agen yang diambil dari jaringan solver tanpa izin, dan solver individual akan mencari pembayaran kembali nanti dari protokol jembatan. Dalam perbandingan, mekanisme pengiriman pesan menentukan secara tepat bagaimana transaksi mereka harus dilaksanakan dan tidak perlu mengandalkan ketersediaan agen.

protokol penyelesaian niat

Protokol jembatan berbasis niat dapat diberi label lebih tepat sebagai protokol penyelesaian niat yang bertanggung jawab untuk memastikan bahwa penyelesaian tidak melanggar kondisi yang ditentukan pengguna. Protokol penyelesaian niat menawarkan keamanan bagi penyelesaian bahwa mereka akan dibayar kembali dan diberi imbalan atas pemenuhan niat pengguna. Untuk melakukannya, protokol penyelesaian niat perlu meminta bantuan dari oracle untuk memverifikasi keaslian pemenuhan niat. Keamanan oracle dapat didasarkan pada periode tantangan optimis, ambang saksi, atau berbasis bukti validitas ZK, misalnya.

Protokol penyelesaian niat menawarkan transfer nilai yang cepat dan murah karena penyelesaian individu dapat mengambil risiko finalitas dan mengidentifikasi jalur eksekusi optimal

Jembatan pengiriman pesan hanya dapat berkomunikasi secepat finalitas yang dicapai oleh rantai asal. Waktu finalitas adalah tujuh hari pada optimistic rollups dan satu jam pada ZK rollups hari ini. Meskipun waktu finalitas ini seharusnya menurun setelah adopsi lebih luas dari teknologi klien ringan ZK dan kemajuan dalam teknologi pra-konfirmasi pembagian-urutan bersama, tidak mungkin bahwa waktu finalitas untuk semua blockchain akan pernah terasa 'seketika' bagi pengguna, menunjukkan kebutuhan yang persisten untuk solusi jembatan yang cepat. Tidak mungkin untuk meneruskan pesan lebih cepat dari periode finalitas tanpa mengasumsikan risiko finalitas - yang berada di luar cakupan jembatan pengiriman pesan - kecuali jembatan ingin menambahkan agen tepercaya tambahan ke jalur penerusan yang akan menutupi kerugian akibat reorganisasi rantai.

Peningkatan kecepatan yang ditawarkan oleh arsitektur berbasis niat muncul karena solver individu dalam jaringan solver heterogen dapat mengasumsikan lebih banyak risiko finalitas daripada yang dapat dilakukan oleh protokol pengiriman pesan dan memenuhi niat pengguna sebelum risiko reorganisasi rantai benar-benar hilang. Solver kemudian akan mengenakan biaya kepada pengguna atas risiko finalitas ini yang mereka asumsikan sebagai imbalan atas waktu pengisian yang lebih cepat.

Mengalihdayakan pemenuhan niat lintas rantai ke agen juga mengarah pada peningkatan harga rata-rata untuk pengguna. Dalam jembatan berbasis niat, pemecah yang melakukan front pesanan pengguna pada rantai tujuan yang diinginkan dilunasi kemudian oleh sistem setelah pemenuhannya divalidasi. Penyelesaian maksud ini dapat dikelompokkan bersama untuk mengamortisasi biaya. Pengisi, tidak seperti pengguna, tidak menuntut pembayaran instan dan akan membebankan biaya yang sesuai kepada pengguna untuk modal di depan mereka. Penyelesaian batch tidak unik untuk arsitektur berbasis intent, tetapi arsitekturnya lebih sinergis dengan penyelesaian batch karena memisahkan langkah pembayaran dari langkah pemenuhan intent.

Sumber perbaikan harga yang lebih besar berasal dari intuisi bahwa nilai dapat dipertukarkan, dan menemukan jalur terbaik tepat waktu biasanya akan mengungguli transfer nilai. (Namun, beberapa jalur akan tidak mungkin dikalahkan dalam biaya tepat waktu, seperti saat memindahkan USDC melalui CCTP.)

Jembatan pertukaran pesan harus mengkodekan bagaimana mereka akan mentransfer nilai ke pengguna. Beberapa memilih untuk mengirimkan token keluar dari kolam likuiditas dengan nilai tukar yang telah ditentukan, sementara yang lain mencetak token perwakilan kepada penerima yang kemudian perlu menukarnya dengan aset token kanon yang diinginkan.

Saat memenuhi maksud pengguna, agen dapat memperoleh likuiditas dari kombinasi tempat likuiditas onchain dan offchain. Jaringan pemecah kompetitif menawarkan kepada pengguna sumber likuiditas tak terbatas secara teori (tetapi bahkan sumber likuiditas ini dapat habis dengan cepat ketika tren volume dalam satu arah selama peristiwa onchain volatilitas tinggi seperti mint NFT populer, airdrop, dan rug pull).

Mengirimkan pesanan lintas-rantai sebagai niat memungkinkan penyelesaian untuk menginternalisasi MEV yang dihasilkan dari pesanan sebagai peningkatan harga.

Arsitektur berbasis niat pada dasarnya dirancang untuk aman

Jembatan berbasis niat dapat dibangun dengan aman karena mereka memisahkan tuntutan mendesak pengguna dari tuntutan kompleks jaringan penyelesaian. Penyelesaian dapat menunggu pembayaran, tidak seperti pengguna, dan mereka akan menagih pengguna untuk jumlah waktu yang jaringan penyelesaian membuat mereka menunggu pembayaran. Oleh karena itu, penyelesaian niat dapat divalidasi menggunakan mekanisme yang sangat kuat tanpa batasan waktu yang ketat. Ini lebih disukai dari sudut pandang keamanan karena memverifikasi pemenuhan niat secara intuitif kompleks.

Sebagai contoh verifikasi niat dalam produksi, Lintangmemvalidasi dan mengembalikan pengisi dalam kelompok mengikuti periode tantangan optimis selama 90 menit. Tentu saja, jaringan penyelesaian harus berupaya untuk mengembalikan pengisi secepat mungkin untuk mengurangi biaya pengguna akhir. Peningkatan pada mekanisme tantangan optimis akan menjadi mekanisme bukti validitas ZK, yang akan memerlukan enkoding logika validasi niat ke dalam sirkuit ZK. Menurut pendapat saya, adalah suatu keniscayaan bahwa mekanisme pembuktian validitas akan menggantikan mekanisme tantangan optimis dan memungkinkan jaringan penyelesaian niat mengembalikan pengguna lebih cepat.

Jadi, bagaimana abstraksi rantai muncul dari arsitektur berbasis niat?

Ingat bahwa abstraksi rantai membutuhkan transfer nilai lintas rantai yang cepat dan murah. Ini juga seharusnya tidak memerlukan pengguna untuk mengirimkan transaksi onchain pada jaringan di mana aset mereka disimpan.

Niat pengguna tidak perlu diserahkan onchain oleh pengguna jika termasuk sebuah Izin2atauEIP3074tanda tangan. Hal ini berlaku baik untuk jembatan berbasis pesan maupun berbasis niat. Kedua arsitektur dapat memanfaatkan pola Permit2 untuk memungkinkan pengguna menandatangani di luar rantai jumlah token yang bersedia mereka bayar dari dompet rantai asal mereka.

Pasar niat terbaik mendukung abstraksi rantai karena mereka menawarkan transfer nilai lintas rantai yang murah dan cepat. Bayangkan sebuah dunia di mana pengguna dapat meminta pemecah untuk memberi mereka penawaran untuk masuk ke posisi staking WETH di Arbitrum, menggunakan USDC mereka di Optimisme sebagai pembayaran. Pengguna dapat mengirim maksud ini offchain ke lelang RFQ di mana pemecah dapat menawarnya. Pemecah lelang yang menang kemudian dapat menerima niat yang ditandatangani pengguna, yang berisi penyisihan untuk membelanjakan USDC mereka di Optimisme, jumlah WETH yang diinginkan untuk diterima di Arbitrum, dan calldata yang diperlukan untuk menyetor WETH ini ke posisi staking di Arbitrum. Pemecah selanjutnya dapat mengirimkan transaksi ini pada Optimisme (atas nama pengguna) untuk memulai niat lintas rantai dan menarik USDC dari dompet Optimisme pengguna. Akhirnya, pemecah dapat mengisi maksud pengguna di Arbitrum dengan mengirimi mereka WETH dan meneruskan calldata untuk memasukkan pengguna ke posisi staking onchain.

Membangun infrastruktur abstraksi rantai berarti membuat alur pengguna ini terasa instan dan murah tanpa memerlukan mereka untuk mengirimkan transaksi onchain. Mari kita akhiri artikel ini dengan membahas hambatan untuk adopsi niat yang lebih luas.

Arsitektur Niat oleh Across

Untuk pengalaman pengguna terbaik untuk terealisasi dari abstraksi rantai berbasis niat, kita memerlukan jaringan solver yang kompetitif

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 jaringan penyelesaian oligopolistik. Namun, status jaringan solver saat ini adalah belum matangdan tidak mendekati pemenuhan asumsi kelangsungan jaringan solver yang diandalkan oleh pasar niat.

Kami tidak ingin dunia di mana setiap dapp mengarahkan niat ke jaringan solver yang terisolasi. Kasus terbaik untuk UX adalah banyak dapp berkomunikasi dengan kolam solver yang sama, dan semua dapp memiliki kebebasan untuk mengubah kolam solver mana yang mereka kirimkan niat mereka.

Bagaimana cara kita memulai jaringan solver?

Kita harus memberikan prioritas pada UX solver.

Menjalankan solver tujuan itu rumit dan memerlukan keahlian dalam membangun perangkat lunak yang sangat performa serta mengelola risiko inventaris lintas-rantai. Secara alami, akan ada pihak terbatas yang tertarik membayar biaya awal untuk menjalankan kode ini. Dalam skenario terbaik, solver yang ditulis untuk satu dapp, seperti solver UniswapX, bisa digunakan kembali untuk menyelesaikan dapp lain yang memproduksi tujuan seperti Across dan CowSwap.

Kita benar-benar perlu meningkatkan efisiensi modal agregat dari jaringan solver untuk semua dapps berbasis keinginan. Hal ini akan memerlukan penyelesaian terhadap hambatan dalam menjalankan sebuah solver.

Untuk ini, kami akan memerlukan dapps yang menghasilkan niat agar terlihat oleh setiap penyelesaian dan memastikan semua penyelesaian memiliki akses ke banyak jaringan penyelesaian niat yang berbeda dan kompetitif. Hal ini akan memberikan kepercayaan kepada penyelesaian bahwa mereka dapat memilih untuk mengarahkan pemenuhan niat mereka ke jaringan penyelesaian yang mereka percayai. Persaingan antara jaringan penyelesaian juga akan menurunkan biaya bagi penyelesaian.

Proposisi nilai dari jaringan penyelesaian maksud adalah menawarkan keamanan kepada penyelesaian serta fitur lain yang akan mempengaruhi kemampuan penyelesaian untuk mengisi maksud.

Pilihan solver terhadap jaringan penyelesaian niat akan memengaruhi kemampuan mereka untuk menawarkan biaya dan jaminan waktu eksekusi kepada pengguna. Beberapa jaringan penyelesaian mungkin menawarkan periode eksklusivitas solver, yang akan mendukung pengembangan lelang offchain di mana solver dan pengguna dapat bernegosiasi dan berkomitmen untuk biaya relay. (Lelang niat ini mungkin juga menawarkan konfirmasi pra-ekonomi yang terikat, yang lebih meningkatkan UX. Untuk mempelajari lebih lanjut tentang alur pengguna yang menampilkan penemuan niat melalui lelang dan konfirmasi pra, saya sarankan ini bicara oleh Karthik dari Sorella.)

Beberapa jaringan penyelesaian mungkin menawarkan kadaluarsa niat (yaitu, mengirim nilai kembali ke pengguna setelah batas waktu pemenuhan tertentu berlalu), penjaminan niat (yaitu, jaringan penyelesaian menggunakan neraca keuangannya sendiri untuk memenuhi niat pengguna jika tidak ada penyelesaian yang dilakukan), atau rantai pembayaran fleksibel (yaitu, memungkinkan penyelesaian untuk dibayar kembali di rantai pilihan mereka).

Pada akhirnya, jaringan penyelesaian akan bersaing dengan ganas untuk mengembalikan solvers dengan cepat dan murah tanpa mengorbankan keamanan. Sebaliknya, solvers akan mengirim aliran pesanan mereka ke jaringan penyelesaian yang memungkinkan mereka menawarkan biaya termurah kepada pengguna sehingga mereka dapat memenangkan aliran pesanan dapp. Persaingan di jaringan penyelesaian dan solver bergantung pada semua pihak dalam rantai pasokan yang bermaksud berkoordinasi untuk berbicara dalam bahasa yang sama, dan persaingan akan menghasilkan pengalaman pengguna terbaik untuk transfer nilai lintas rantai.

Jelas bahwa kita memerlukan standar untuk niat lintas-rantai

Jika solver dapat mengasumsikan bahwa niat akan berbagi elemen umum, maka mereka dapat menggunakan kembali kode mereka untuk memecahkan niat yang berasal dari dapp yang berbeda dan kemudian menurunkan biaya pengaturan mereka. Jika dapp yang berbeda membuat niat yang sesuai dengan standar yang sama, maka mereka semua dapat mengarahkan niat mereka ke pool solver yang sama. Ini akan membantu memasukkan generasi berikutnya dari dapp dengan memberi mereka kemampuan untuk menyambungkan niat lintas-rantai mereka langsung ke dalam pool solver yang ada dan matang. Dapp baru tidak perlu secara individual memasukkan solver dan, sebaliknya, akan mendapatkan akses ke transfer nilai yang murah, cepat, aman, dan tanpa izin.

Perangkat lunak pelacakan pihak ketiga juga akan lebih mudah melacak status niat untuk setiap dapp baru jika mereka sesuai dengan standar.

Standar niat ini harus memungkinkan prinsipal niat atau solver untuk menentukan jaringan penyelesaian mana yang ingin mereka gunakan untuk menyelesaikan niat mereka.

Saya membayangkan protokol penyelesaian yang bersaing seperti SUAVE, Across, Anoma, dan Khalani menawarkan fitur yang berbeda kepada penyelesaian solvers. Tergantung pada jaringan penyelesaian yang membayar solvers, solvers dapat menawarkan jaminan harga dan waktu yang berbeda kepada pemilik niat. Dapp dan solvers dapat setuju untuk merutekan niat pengguna ke jaringan penyelesaian yang mereka percayai untuk menghindari sensor, menjaga privasi data, dan juga cukup aman untuk dipercayai untuk membayar kembali solvers.

Dengan menyematkan pilihan jaringan penyelesaian ke dalam pesanan niat itu sendiri, penyelesaian dapat memastikan kepastian ini ke dalam kutipan yang akan mereka tunjukkan kepada pengguna. Penyelesaian dan pengguna akan menghilangkan ketidakpastian awal tentang penetapan harga jembatan sebelum mengirimkan niat secara onchain, mengurangi biaya.

Dalam kolaborasi dengan Uniswap dan berdasarkan umpan balik dari kelompok kerja CAKE, Across dan saya mengusulkan standar niat lintas rantai berikut yang memprioritaskan UX solver:

///@titlejenis Pesanan CrossChain

///@noticeStruktur pesanan standar yang akan ditandatangani oleh penukar, disebarluaskan kepada pengisi, dan disampaikan ke kontrak penyelesaian

struktur CrossChainOrder {

/// @dev Alamat kontrak yang dimaksudkan untuk diselesaikan oleh pesanan./// Pengirim mengirim pesanan ini ke alamat kontrak ini di rantai asalalamat settlementContract;/// @dev Alamat pengguna yang memulai pertukaran,/// token inputnya akan diambil dan dijaminkanalamat swapper;/// @dev Nomor acak yang akan digunakan sebagai perlindungan replay untuk pesananuint256 nonce;/// @dev Id rantai dari rantai asaluint32 originChainId;/// @dev Cap waktu di mana pesanan harus diinisiasiuint32 initiateDeadline;/// @dev Cap waktu di mana pesanan harus diisi di rantai tujuanuint32 fillDeadline;/// @dev Data spesifik implementasi sembarang/// Dapat digunakan untuk mendefinisikan token, jumlah, rantai tujuan, biaya, parameter penyelesaian,/// atau informasi spesifik jenis pesanan lainnyabytes orderData;

}

Standar ini dirancang untuk memudahkan pekerjaan solver. Salah satu pilihan tegas yang dibuatnya adalah mendukung Permit2/EIP3074 secara native dengan nonce dan initiateDeadline dan memberikan beberapa jaminan kepada pengisi, seperti jumlah yang akan mereka dapatkan kembali dari jaringan penyelesaian dan format niat pengguna yang dapat mereka lacak. Selain itu, fungsi inisiasi didefinisikan dalam standar yang secara krusial memungkinkan pengisi, orang yang akan membawa pesanan onchain, untuk menentukan "fillerData" tambahan onchain yang tidak diketahui pengguna pada saat mereka menandatangani CrossChainOrder. Hal ini memungkinkan pengisi untuk memastikan bahwa mereka dikompensasi oleh kontrak penyelesaian atas pengiriman meta-transaksi pengguna dan juga menetapkan informasi spesifik tentang pembayaran seperti rantai pembayaran.

Standar ini juga dirancang untuk memudahkan dapps melacak status pemenuhan niat sepanjang siklus hidupnya. Setiap kontrak penyelesaian yang mengimplementasikan standar ini harus membuat sub-tipe khusus ResolvedCrossChainOrder yang dapat diparsing dari bidang orderData sewenang-wenang. Ini mungkin mencakup informasi seperti token yang terlibat dalam pertukaran, rantai tujuan, dan kendala pemenuhan lainnya. Fungsi resolve disertakan dalam standar untuk memungkinkan dapps memahami cara menampilkan status niat kepada pengguna dan untuk para penyelesaian mengetahui struktur pesanan niat yang tepat dengan yang mereka kerjakan.

///@titleJenis Pesanan ResolvedCrossChain

///@noticeRepresentasi generik implementasi dari sebuah pesanan

///@devMenentukan semua persyaratan untuk mengisi pesanan dengan membongkar data pesanan yang spesifik implementasinya.

/// @devBermaksud untuk meningkatkan generalisasi integrasi dengan memungkinkan pengisi untuk menghitung informasi input dan output yang tepat dari setiap urutan

struct ResolvedCrossChainOrder {

/// @dev Alamat kontrak yang dimaksudkan untuk diselesaikan oleh alamat kontrak penyelesaian; /// @dev Alamat pengguna yang memulai pertukaran alamat swapper; /// @dev Nonce yang akan digunakan sebagai perlindungan replay untuk pesanan uint256 nonce; /// @dev ChainId dari chain asal uint32 originChainId; /// @dev Timestamp di mana pesanan harus diinisiasi uint32 initiateDeadline; /// @dev Timestamp di mana pesanan harus diisi di rantai tujuan uint32 fillDeadline; /// @dev Input yang akan diambil dari swapper sebagai bagian dari inisiasi pesanan Input[] swapperInputs; /// @dev Output yang akan diberikan kepada swapper sebagai bagian dari pemenuhan pesanan Output[] swapperOutputs; /// @dev Output yang akan diberikan kepada filler sebagai bagian dari penyelesaian pesanan Output[] fillerOutputs;

}

///@noticeToken yang dikirim oleh swapper sebagai input ke order

struct Input {

/// @dev Alamat token ERC20 di rantai asalalamat token;/// @dev Jumlah token yang akan dikirimuint256 jumlah;

}

///@noticeToken yang harus diterima untuk pemenuhan pesanan yang valid

struct Output {

/// @dev Alamat token ERC20 di rantai tujuan/// @dev alamat(0) digunakan sebagai penanda untuk token asli alamat token;/// @dev Jumlah token yang akan dikirimuint256 jumlah;/// @dev Alamat untuk menerima token outputalamat penerima;/// @dev Rantai tujuan untuk output iniuint32 chainId;

}

Implementasi kontrak penyelesaian yang patuh HARUS mengimplementasikan antarmuka ISettlementContract:

///@titleISettlementContract

///@noticeAntarmuka standar untuk kontrak penyelesaian

antarmuka ISettlementContract {

/// @notice Memulai penyelesaian pesanan lintas rantai/// @dev Akan dipanggil oleh pengisi/// @param pesanan Definisi CrossChainOrder/// @param tanda tangan Tanda tangan swapper atas pesanan/// @param fillerData Data yang ditentukan oleh pengisi yang diperlukan oleh penyelesaifungsi memulai(CrossChainOrder pesanan, byte tanda tangan, byte fillerData) eksternal;/// @notice Memecahkan pesanan CrossChain tertentu menjadi ResolvedCrossChainOrder generik/// @dev Dimaksudkan untuk meningkatkan integrasi standar berbagai jenis pesanan dan kontrak penyelesaian/// @param pesanan Definisi CrossChainOrder/// @param fillerData Data yang ditentukan oleh pengisi yang diperlukan oleh penyelesaifungsi memecahkan(CrossChainOrder pesanan, byte fillerData) eksternal tampilan kembali (ResolvedCrossChainOrder);

}

Tujuan desain standar ini adalah untuk meningkatkan UX solver, memudahkan mereka mendukung jaringan penyelesaian ganda, dan menghitung imbalan mereka secara deterministik. Saya percaya hal ini akan memungkinkan mereka memberikan penawaran yang lebih akurat dan ketat kepada pengguna. Anda dapat membaca lebih banyak detail tentang standar ini, yang memiliki kode nama ERC7683, di postingan X/Twitter inidan diskusi yang mengelilinginyadi forum Ethereum Magicians.

Pemikiran Penutup

"Tujuan" membingungkan karena tidak didefinisikan, dan kurangnya definisi ini menciptakan cacat UX yang nyata.

Semua orang ingin orang lain menggunakan definisi standar mereka tentang sebuah niat, jadi saya sepenuhnya mengakui bahwa standar hampir tidak mungkin untuk ditetapkan. Saya tidak berpikir bahwa mendefinisikan sistem penyelesaian niat terlebih dahulu dan mencoba menarik aliran pesanan kedua adalah pendekatan yang tepat untuk menetapkan standar di seluruh industri.

Menurut pendapat saya, pendekatan yang lebih mudah adalah bagi dapps yang sudah memiliki banyak aliran pengguna dan berasal dari banyak niat pengguna akan setuju untuk mematuhi beberapa standar minimal yang akan diadopsi oleh solver mereka yang sudah ada. Ini akan membentuk kolam solver baru dan lebih besar. Dengan mendapatkan akses ke orderflow yang digabungkan dari tempat-tempat terkemuka yang sudah ada, kolam solver baru ini akan mendapatkan lebih banyak keuntungan dan dapat menawarkan harga yang lebih baik kepada pengguna akhir. Pada akhirnya, dapps baru juga akan menuntut untuk mengarahkan niat mereka ke kolam solver ini dan akan mendukung standar niatnya.

Untuk memulai, Across dan Uniswap bekerja sama mengusulkan sebuah standaruntuk semua pihak rantai pasokan menggunakan saat menangani pesanan pengguna untuk mengirim token X dari rantai A dan menerima token Y di rantai B. Alur pesanan yang berjalan melalui UniswapX (memiliki keunggulan komparatif dalam desain pelelangan dan maksud asal) dan Across (memiliki keunggulan komparatif dalam pemenuhan maksud) dapat bergabung dan memulai proses pembibitan jaringan penyelesaian yang lebih besar dan lebih kompetitif.

Penafian：

1. Artikel ini dicetak ulang dari [Cermin], Semua hak cipta milik penulis asli [Nick Pai]. Jika ada keberatan terhadap pencetakan ulang ini, silakan hubungi Gate Learntim, dan mereka akan menanganinya dengan cepat.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.