Analisis: Penggantian nonce Solana akan mempertahankan persetujuan setelah transaksi gagal

Rencana Solana Foundation pada Oktober mengusulkan penggantian nonce tahan lama dengan program penanda tangan on-chain yang memverifikasi tanda tangan offline dan mengeksekusi instruksi yang disetujui. Alamat turunan program (PDA) akan mengendalikan akun yang terdampak, sementara kunci asli menyetujui tindakan dan operator online terpisah mengirim transaksi serta membayar biaya jaringan. Bursa, kustodian, dan operator perbendaharaan perlu memigrasikan aset atau izin, memastikan aplikasi menerima jalur eksekusi baru, dan memperoleh persetujuan tim risiko.

Nonce tahan lama tetap dapat digunakan, dan Foundation belum menetapkan tanggal penghapusannya ataupun memilih antara Programmatic Signer dari Anza dan Vector dari Blueshift. Jangka waktu migrasi sekitar enam bulan bergantung pada tersedianya pengganti yang sesuai, telah diaudit, dan aktif di mainnet. Nonce tahan lama memungkinkan persetujuan offline dan pengiriman transaksi di kemudian hari dengan menggunakan nonce tersimpan, alih-alih hash blok terbaru yang segera kedaluwarsa. Peningkatan slot Solana yang terpisah selama 200ms mencapai tahap akhir di mainnet pada 9 Oktober, sehingga mengurangi waktu persetujuan biasa, meskipun kedaluwarsa mengikuti produksi blok, bukan pengatur waktu yang terjamin.

Dengan Programmatic Signer, kunci dingin menandatangani pesan otorisasi yang dikirim oleh relayer dalam transaksi dengan hash blok baru untuk diverifikasi dan dieksekusi menggunakan alamat turunan. PDA tidak memiliki kunci privat; kewenangannya berasal dari verifikasi persetujuan kunci asli dan memerlukan pemindahan aset atau izin secara terpisah. Panduan migrasi menjelaskan pemindahan SOL asli, saldo token, izin pencetakan atau pembekuan, serta kewenangan staker, kewenangan penarikan, atau keduanya pada akun staking ke alamat turunan. Foundation mengusulkan agar pemindahan-pemindahan terpisah ini diselesaikan saat nonce tahan lama lama masih berfungsi, dengan inventaris akun dan izin kunci yang sudah ada pada setiap perbendaharaan menentukan perubahan yang diperlukan. Akun SOL turunan Programmatic Signer dimiliki oleh System dan dapat mengirim SOL melalui transfer biasa yang disetujui. Namun, Vector menginisialisasi akun milik program dan menyalurkan SOL melalui operasi penarikan atau penutupan yang diotorisasi.

Dokumentasi pesan Programmatic Signer menyebutkan bahwa tanda tangan kunci dingin mengikat eksekutor, akun nonce, dan pesan eksekusi yang disematkan, sehingga relayer tidak dapat mengubah byte yang diotorisasi tersebut. Relayer dapat memilih pembayar biaya dan hash blok pada transaksi luar serta menambahkan instruksi sebelum atau sesudah pengiriman. Vector mengikat buffer instruksi tingkat atas, termasuk data dan akun untuk pemanggilan yang disetujui ke program lain, sehingga mencegah penyisipan, penghapusan, atau pengurutan ulang instruksi di sekitarnya setelahnya. Programmatic Signer mengizinkan konteks eksekusi disusun di sekitar tindakan yang disetujui, sedangkan Vector mensyaratkan persetujuan terlebih dahulu atas rangkaian instruksi di sekitarnya; keduanya tidak memberi pembayar biaya izin untuk mengubah tindakan yang telah ditandatangani.

Transaksi nonce tahan lama saat ini menggunakan nonce-nya jika validasi berhasil tetapi eksekusi gagal. Programmatic Signer menerapkan pembaruan nonce dan perubahan aplikasi secara bersamaan atau membatalkan keduanya. Dokumentasi Vector menjelaskan kemampuan percobaan ulang yang sama, artinya pengiriman yang gagal dapat membuat persetujuan tetap bisa dieksekusi di kemudian hari selama nonce tidak berubah dan tidak ada tenggat waktu. Vector memperingatkan bahwa relayer dapat menahan transaksi sampai kondisinya berubah, atau tanda tangan yang terekspos dalam upaya yang gagal dapat dieksekusi kemudian. Batas waktu dalam instruksi yang ditandatangani dapat menolak eksekusi setelah tenggat. Pencabutan memerlukan pembaruan nonce terpisah yang diotorisasi dan berhasil dicatat. Penolakan karena tenggat tidak menggunakan nonce jika perubahan nonce dibatalkan bersama transaksi yang gagal.

Alasan yang dikemukakan Foundation adalah penyederhanaan penanganan validator, karena nonce tahan lama memerlukan aturan khusus pencegahan pemutaran ulang, mempersulit eksekusi asinkron, dan membuat transaksi tidak valid lebih sulit disaring. Dengan memindahkan status persetujuan dan pemutaran ulang ke program biasa, validator tetap memproses transaksi dengan hash blok normal, sementara aplikasi menerima tindakan yang disetujui melalui pemanggilan lintas program (CPI). Aplikasi yang memerlukan tindakan tingkat atas dapat menolak jalur ini, sementara pemeriksaan yang hanya mencakup instruksi pembayaran kembali atau verifikasi tanda tangan tingkat atas dapat melewatkan tindakan yang tersarang di dalam program penanda tangan. Kedalaman pemanggilan tambahan tidak dapat mengatasi aturan yang menolak posisi suatu pemanggilan atau tidak dapat memeriksa instruksi tersarang. Foundation menyarankan dukungan untuk program penanda tangan yang diketahui atau penyediaan jalur eksekusi lain. Penerimaan tanda tangan PDA oleh aplikasi terpisah dari validitas kriptografis persetujuan offline.

Dengan CPI Guard Token-2022 diaktifkan, transfer dan pembakaran melalui CPI memerlukan kewenangan delegasi, persetujuan CPI dilarang, dan perubahan pemilik dilarang bahkan di luar CPI. Delegasi permanen memiliki pengecualian untuk transfer dan pembakaran, sementara kemungkinan jalur transfer berbasis delegasi memerlukan keputusan terpisah mengenai izin dan kebijakan kustodi. Dalam diskusi pada 4 Maret, seorang peserta yang menyebut dirinya Michael dari Fireblocks mendukung penghapusan nonce tetapi keberatan dengan beban migrasi, ketergantungan pada kontrak, dan kompatibilitas DeFi pada CPI Passthrough. Michael memilih transaction envelope, dengan Sudo sebagai alternatif, alih-alih jalur penandatanganan berbasis CPI yang diusulkan. Grant, yang menyebut dirinya bekerja di Unit 410, mengatakan pada hari yang sama bahwa program penanda tangan kecil yang dapat diaudit mungkin membuat migrasi kewenangan dapat diterima. Grant menolak pemindahan aset sementara ke penanda tangan hot, bahkan secara atomik, karena dana harus tetap terkait dengan penyimpanan dingin berdasarkan model nonkustodian Unit 410.

Dokumentasi Programmatic Signer melaporkan penerapan di devnet dan audit yang masih berlangsung, mensyaratkan perbaikan sebelum rilis v1 dan penerapan apa pun di mainnet, serta memperingatkan bahwa antarmuka dapat berubah. Dokumentasi penggunaan Programmatic Signer menyebut simulasi dan pengiriman melalui relay sebagai fitur yang akan segera tersedia, sementara panduan migrasi juga menyebut sejumlah operasi belum selesai. Vector menerbitkan kode implementasi dan ID program, tetapi README Vector tidak menyebutkan status audit atau penerapan di mainnet. Perangkat onboarding protokol Fireblocks saat ini menjelaskan penyisipan nonce tahan lama otomatis untuk integrasi WalletConnect tertentu, termasuk Jupiter dan Kamino, dengan masa berlaku 15 menit secara default yang dikelola penyedia dan perlu diakomodasi oleh penggantinya.