Pengantar:

Sejak diumumkannya UniswapV4, platform swap ini telah mengalami transformasi signifikan, berkembang dari platform swap sederhana menjadi penyedia layanan infrastruktur. Secara khusus, fitur Hooks pada V4 telah mendapat perhatian luas. Setelah penelitian mendalam, saya telah mengumpulkan beberapa konten untuk membantu semua orang lebih memahami transformasi ini dan implementasinya.

Fokus inovasi UniswapV4 tidak hanya pada peningkatan teknologi AMM tetapi juga pada perluasan ekosistem. Secara khusus, inovasi ini mencakup fitur-fitur utama berikut:

• Akuntansi Flash
• Kontrak Tunggal
• Arsitektur Kait

Pada bagian berikut, saya akan menjelaskan secara rinci pentingnya fitur-fitur ini dan prinsip penerapannya.

sumber: https://twitter.com/jermywkh/status/1670779830621851650

Akuntansi Flash

Pembukuan Entri Ganda

UniswapV4 mengadopsi metode pencatatan yang mirip dengan Pembukuan Entri Ganda untuk melacak perubahan saldo token yang terkait dengan setiap operasi. Metode Pembukuan Double Entry ini mengharuskan pencatatan setiap transaksi pada beberapa akun secara bersamaan dan memastikan saldo aset antar akun tersebut tetap seimbang. Misalnya, pengguna menukar 100 TokenA dengan 50 TokenB dari pool. Catatan dalam buku besar adalah sebagai berikut:

• PENGGUNA: TokenA berkurang 100 unit (-100), sedangkan TokenB bertambah 50 unit (+50).
• POOL: TokenA bertambah 100 unit (+100), sedangkan TokenB berkurang 50 unit (-50).

Token Delta dan Operasi Terkait

Di UniswapV4, metode pencatatan ini terutama digunakan untuk operasi besar, dan variabel penyimpanan bernama lockState.currencyDelta[currency] digunakan dalam kode untuk mencatat jumlah perubahan saldo token. Jika nilai delta ini positif, maka ini mewakili perkiraan peningkatan jumlah token di kumpulan, sedangkan nilai negatif mewakili perkiraan penurunan jumlah token. Alternatifnya, jika nilainya positif, ini menunjukkan jumlah kekurangan token di pool (jumlah yang diharapkan akan diterima), sedangkan nilai negatif menunjukkan kelebihan token di pool (jumlah yang diharapkan untuk ditarik oleh pengguna). Daftar berikut menunjukkan efek dari berbagai operasi pada Token Delta:

• memodifikasiPosition: Mewakili operasi Tambah/Hapus likuiditas. Untuk Tambah likuiditas, TokenDelta diperbarui menggunakan penambahan (mewakili jumlah TokenA yang diharapkan akan ditambahkan ke kumpulan). Untuk Hapus likuiditas, TokenDelta diperbarui menggunakan pengurangan (mewakili jumlah TokenB yang diharapkan untuk ditarik dari kumpulan).
• swap: Mewakili operasi Swap. Mengambil contoh pertukaran TokenA dengan TokenB, TokenADelta diperbarui menggunakan penjumlahan, sedangkan TokenBDelta diperbarui menggunakan pengurangan.
• menetap: Mendampingi transfer token ke pool. Kumpulan menghitung peningkatan jumlah token sebelum dan sesudah dan memperbarui TokenDelta menggunakan pengurangan. Jika kumpulan menerima jumlah token yang diharapkan, pengurangan akan menghilangkan TokenDelta.
• take: Mendampingi penarikan token dari pool. TokenDelta diperbarui menggunakan penambahan, yang menunjukkan bahwa token telah dihapus dari kumpulan.
• mint: Perilaku memperbarui TokenDelta mirip dengan “mengambil”, tetapi alih-alih menarik token dari kumpulan, token ERC1155 dikeluarkan sebagai bukti penarikan, sementara token tetap berada di kumpulan. Nantinya, pengguna dapat mengambil token dari pool dengan membakar token ERC1155. Tujuan pendekatan ini ada dua: 1. Menghemat biaya bahan bakar untuk transfer token ERC20 (panggilan kontrak + satu penyimpanan lebih sedikit), dan menggunakan pembakaran token ERC1155 di masa mendatang untuk memperbarui TokenDelta untuk transaksi. 2. Pertahankan likuiditas di pool untuk mempertahankan pool likuiditas yang dalam untuk pengalaman pertukaran pengguna yang lebih baik.
• donate: Operasi ini mendeklarasikan donasi token ke pool, namun kenyataannya, token masih perlu ditransfer ke pool menggunakan “settle.” Oleh karena itu, TokenDelta diperbarui menggunakan penambahan dalam kasus ini.

Di antara operasi ini, hanya “menyelesaikan” dan “mengambil” yang melibatkan transfer token sebenarnya, sementara operasi lainnya sepenuhnya bertanggung jawab untuk memperbarui nilai TokenDelta.

Contoh Token Delta

Di sini kami menggunakan contoh sederhana untuk mengilustrasikan cara memperbarui TokenDelta. Misalkan hari ini kita menukar 100 TokenA dengan 50 TokenB:

1. Sebelum transaksi dimulai, TokenADelta dan TokenBDelta bernilai 0.
2. swap: Hitung berapa banyak TokenA yang perlu diterima Pool dan berapa banyak TokenB yang akan diterima pengguna. Pada titik ini, TokenADelta = 100, TokenBDelta = -50.
3. penyelesaian: Kirim 100 TokenA ke Pool dan perbarui TokenADelta = 100 - 100 = 0.
4. ambil: Transfer 50 TokenB dari Pool ke akun pengguna dan perbarui TokenBDelta = -50 + 50 = 0.
5. Setelah transaksi selesai, baik TokenADelta maupun TokenBDelta bernilai 0.

Ketika seluruh operasi pertukaran selesai, TokenADelta dan TokenBDelta diatur ulang ke 0. Ini berarti bahwa operasi telah sepenuhnya seimbang, sehingga memastikan konsistensi saldo akun.

EIP-1153: Opcode penyimpanan sementara

Sebelumnya disebutkan bahwa UniswapV4 menggunakan Variabel Penyimpanan untuk mencatat TokenDelta. Namun, dalam kontrak, membaca dan menulis ke Variabel Penyimpanan cukup mahal. Ini membawa kita ke EIP lain yang diperkenalkan oleh Uniswap: EIP1153 - Transient Storage Opcodes.

UniswapV4 berencana menggunakan opcode TSTORE dan TLOAD yang disediakan oleh EIP1153 untuk memperbarui TokenDelta. Variabel Penyimpanan yang mengadopsi Opcode Penyimpanan Sementara akan dibuang setelah transaksi berakhir (mirip dengan Variabel Memori), sehingga mengurangi biaya bahan bakar.

EIP1153 telah dikonfirmasi untuk disertakan dalam pemutakhiran Cancun yang akan datang, dan UniswapV4 juga menyatakan bahwa itu akan ditayangkan setelah pemutakhiran Cancun, seperti yang dilaporkan di sini.

sumber: https://etherworld.co/2022/12/13/transient-storage-for-beginners/

Akuntansi Flash — Kunci

UniswapV4 memperkenalkan mekanisme kunci, yang berarti sebelum melakukan operasi Pool apa pun, Anda harus memanggil PoolManager.lock() terlebih dahulu untuk mendapatkan kunci. Selama eksekusi lock(), ia memeriksa apakah nilai TokenDelta adalah 0, jika tidak maka akan dikembalikan. Setelah PoolManager.lock() berhasil diperoleh, fungsi lockAcquired() dari msg.sender akan dipanggil. Di dalam fungsi lockAcquired(), operasi yang terkait dengan Kumpulan, seperti swap dan modifikasiPosition, dilakukan.

Prosesnya diilustrasikan di bawah ini. Ketika pengguna perlu melakukan operasi Token Swap, mereka harus memanggil Kontrak Cerdas dengan fungsi lockAcquired() (disebut sebagai Kontrak Panggilan Balik). Kontrak Callback pertama-tama memanggil PoolManager.lock(), lalu PoolManager memanggil fungsi lockAcquired() dari Kontrak Callback. Di dalam fungsi lockAcquired(), logika yang terkait dengan operasi Kumpulan, seperti swap, penyelesaian, dan pengambilan, didefinisikan. Terakhir, ketika lock() akan segera berakhir, PoolManager memeriksa apakah TokenDelta yang terkait dengan operasi ini telah disetel ulang ke 0, memastikan saldo aset di Pool tetap utuh.

Kontrak Tunggal

Kontrak Singleton berarti UniswapV4 telah meninggalkan model Factory-Pool sebelumnya. Setiap Kumpulan tidak lagi merupakan Kontrak Cerdas yang independen, namun semua Kumpulan berbagi satu kontrak tunggal. Desain ini, dikombinasikan dengan mekanisme Flash Accounting, hanya memerlukan pembaruan Variabel Penyimpanan yang diperlukan, sehingga semakin mengurangi kompleksitas dan biaya pengoperasian.

Pada contoh di bawah, dengan menggunakan UniswapV3 sebagai contoh, menukar ETH dengan DAI akan memerlukan setidaknya empat transfer Token (operasi penulisan Penyimpanan). Ini mencakup beberapa perubahan yang dicatat untuk Token USDC, USDT, dan DAI. Namun, dengan peningkatan pada UniswapV4, ditambah dengan mekanisme Flash Accounting, hanya diperlukan satu transfer Token (memindahkan DAI dari Pool ke pengguna), sehingga mengurangi jumlah operasi dan biaya secara signifikan.

sumber: https://twitter.com/Uniswap/status/1671208668304486404

Arsitektur Kait

Pada pembaruan terbaru UniswapV4, fitur yang paling menonjol adalah Arsitektur Hooks. Pembaruan ini menghadirkan fleksibilitas luar biasa dalam hal ketersediaan Kumpulan. Hooks adalah tindakan tambahan yang dipicu melalui Kontrak Hooks saat melakukan operasi tertentu di Pool. Tindakan ini dikategorikan menjadi inisialisasi (membuat kumpulan), memodifikasiPosition (menambah/menghapus likuiditas), menukar, dan menyumbang. Setiap kategori memiliki tindakan pra-eksekusi dan pasca-eksekusi.

• sebelum Inisialisasi / setelah Inisialisasi
• sebelumModifyPosition / setelahModifyPosition
• sebelum Swap / sesudah Swap
• sebelum Donasi / setelah Donasi

Desain ini memungkinkan pengguna untuk menjalankan logika khusus sebelum dan sesudah operasi tertentu, membuatnya lebih fleksibel dan memperluas fungsionalitas UniswapV4.

sumber: https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf

Contoh Kait — Kait Batas Pesanan

Selanjutnya, kita akan menggunakan contoh Limit Order untuk menjelaskan proses pengoperasian Hooks yang sebenarnya di UniswapV4. Sebelum kita mulai, mari kita jelaskan secara singkat prinsip penerapan Limit Order di UniswapV4.

Mekanisme Limit Order UniswapV4

Implementasi limit order UniswapV4 bekerja dengan menambahkan likuiditas ke kisaran harga tertentu dan kemudian mengeksekusi operasi penghapusan likuiditas jika likuiditas dalam kisaran tersebut ditukar.

Misalnya saja kita menambahkan likuiditas pada kisaran harga 1900-2000 untuk ETH, lalu harga ETH naik dari 1800 ke 2100. Pada titik ini, semua likuiditas ETH yang sebelumnya kami tambahkan pada kisaran harga 1900-2000 telah ditukar dengan USDC (dengan asumsi dalam kumpulan ETH-USDC). Dengan menghilangkan likuiditas pada saat ini, kita dapat mencapai efek serupa dengan mengeksekusi order pasar ETH pada kisaran harga saat ini yaitu tahun 1900-2000.

Batasi Kontrak Kait Pesanan

Contoh ini diambil dari GitHub UniswapV4. Pada contoh ini, kontrak Limit Order Hook menyediakan dua hook yaitu afterInitialize dan afterSwap. Hook afterInitialize digunakan untuk mencatat kisaran harga (centang) saat membuat pool, untuk menentukan limit order mana yang telah dicocokkan setelah seseorang melakukan swap.

Buat Pesanan

Ketika pengguna perlu melakukan pemesanan, kontrak Hook menjalankan operasi penambahan likuiditas berdasarkan kisaran harga dan kuantitas yang ditentukan pengguna. Dalam kontrak Hook untuk limit order, Anda dapat melihat fungsi place() . Logika utamanya adalah memanggil fungsi lockAcquiredPlace() setelah memperoleh kunci untuk menjalankan operasi penambahan likuiditas, yang setara dengan menempatkan limit order.

sumber: https://github.com/Uniswap/v4-periphery/blob/main/contracts/hooks/examples/LimitOrder.sol#L246

setelah Swap Hook

Setelah pengguna menyelesaikan Token Swap dalam Kumpulan ini, Kumpulan akan memanggil fungsi afterSwap() dari kontrak Hook. Logika utama afterSwap adalah menghilangkan likuiditas pesanan yang ditempatkan sebelumnya yang telah dieksekusi antara kisaran harga sebelumnya dan kisaran harga saat ini. Perilaku ini setara dengan pesanan yang dipenuhi.

sumber: https://github.com/Uniswap/v4-periphery/blob/main/contracts/hooks/examples/LimitOrder.sol#L192

Batasi Aliran Pesanan

Berikut adalah diagram alur yang menggambarkan proses eksekusi limit order:

1. Pelaku pemesanan mengirimkan pesanan ke kontrak Hook.
2. Kontrak Hook menjalankan operasi penambahan likuiditas berdasarkan informasi pesanan.
3. Pengguna biasa melakukan operasi Token Swap di Pool.
4. Setelah operasi Swap Token selesai, Pool memanggil fungsi afterSwap() dari kontrak Hook.
5. Kontrak Hook mengeksekusi operasi penghapusan likuiditas untuk limit order yang terisi berdasarkan variasi kisaran harga token yang ditukar.

Di atas adalah keseluruhan proses penerapan Limit-Order menggunakan mekanisme Hook.

Kait: Fitur lainnya

Hooks memiliki beberapa poin menarik yang menurut saya layak untuk dibagikan.

Bit Alamat Kontrak Hooks

Keputusan untuk melakukan operasi tertentu sebelum/sesudah ditentukan oleh 1 byte paling kiri dari alamat kontrak Hook. 1 byte sama dengan 8 bit, yang setara dengan 8 tindakan tambahan. Pool akan memeriksa apakah bit tindakan tersebut adalah 1 untuk menentukan apakah akan menjalankan fungsi hook yang sesuai dari kontrak Hook. Ini juga berarti bahwa alamat kontrak Hook perlu dirancang secara spesifik dan tidak dapat dipilih secara sembarangan sebagai kontrak Hook. Desain ini terutama ditujukan untuk mengurangi konsumsi gas dan mengalihkan biaya ke penerapan kontrak untuk mencapai operasi yang lebih efisien. (PS: Dalam praktiknya, garam CREATE2 yang berbeda dapat digunakan untuk menghitung secara brute force alamat kontrak yang memenuhi ketentuan)

Biaya Dinamis

Selain dapat melakukan operasi tambahan sebelum dan sesudah setiap tindakan, Hooks juga mendukung penerapan biaya dinamis. Saat membuat Kumpulan, Anda dapat menentukan apakah akan mengaktifkan biaya dinamis. Jika biaya dinamis diaktifkan, fungsi getFee() dari kontrak Hook dipanggil saat menukar token. Kontrak Hook dapat menentukan jumlah biaya yang akan dibebankan berdasarkan keadaan Pool saat ini. Desain ini memungkinkan penghitungan biaya yang fleksibel berdasarkan keadaan sebenarnya, sehingga meningkatkan fleksibilitas sistem.

Pembuatan Kolam Renang

Setiap Kumpulan perlu menentukan kontrak Hook selama pembuatannya, dan kontrak tersebut tidak dapat diubah setelahnya (walaupun Kumpulan yang berbeda dapat berbagi kontrak Hook yang sama). Hal ini terutama karena Hooks dianggap sebagai bagian dari PoolKey, dan PoolManager menggunakan PoolKey untuk mengidentifikasi Pool mana yang akan dioperasikan. Sekalipun asetnya sama, namun jika kontrak Hooknya berbeda, maka akan dianggap sebagai Pool yang berbeda. Desain ini memastikan bahwa status dan pengoperasian Kumpulan yang berbeda dapat dikelola secara independen, sehingga memastikan konsistensi Kumpulan. Namun, ini juga meningkatkan kompleksitas perutean seiring dengan bertambahnya jumlah Pool (mungkin UniswapX dirancang untuk mengatasi masalah ini).

TL;DR

• Flash Accounting digunakan untuk melacak perubahan kuantitas setiap token untuk memastikan bahwa semua perubahan dihilangkan setelah menyelesaikan transaksi. Untuk menghemat biaya bahan bakar, Flash Accounting menggunakan metode penyimpanan khusus yang disediakan oleh EIP1153.
• Desain Kontrak Tunggal membantu mengurangi konsumsi gas dengan menghindari pembaruan pada beberapa variabel penyimpanan.
• Arsitektur hooks menyediakan operasi tambahan, dibagi menjadi tahap pra-eksekusi dan pasca-eksekusi. Hal ini memungkinkan lebih banyak fleksibilitas dalam setiap operasi Kumpulan tetapi juga membuat perutean Kumpulan menjadi lebih kompleks.

UniswapV4 dengan jelas menekankan perluasan seluruh ekosistem Uniswap, mengubahnya menjadi infrastruktur untuk memungkinkan lebih banyak layanan dibangun di atas fondasi Uniswap Pools. Hal ini membantu meningkatkan daya saing Uniswap dan mengurangi risiko layanan alternatif. Namun, apakah hal ini akan mencapai keberhasilan yang diharapkan masih harus dilihat. Beberapa hal penting termasuk kombinasi Flash Accounting dan EIP1153, dan kami yakin akan lebih banyak layanan yang mengadopsi fitur ini di masa depan, sehingga menghasilkan berbagai skenario aplikasi. Ini adalah konsep inti UniswapV4, dan kami berharap ini memberikan pemahaman yang lebih mendalam tentang cara kerja UniswapV4. Jika ada kesalahan dalam artikel ini, silakan tunjukkan. Kami juga menyambut diskusi dan masukan.

Terakhir, kami ingin mengucapkan terima kasih kepada Anton Cheng dan Ping Chen karena telah meninjau artikel ini dan memberikan masukan yang berharga!

Penafian:

1. Artikel ini dicetak ulang dari [medium]. Semua hak cipta milik penulis asli [林瑋宸 Albert Lin]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi tim Gate Learn（gatelearn@gate.io）, dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.