Analisis: Usulan BNB Chain membagi kewenangan aset ke dalam empat peran

Rancangan CAS20 yang diusulkan BNB Chain membagi kewenangan aset ke dalam empat peran, sementara administrator yang ditunjuk melalui tata kelola mengendalikan kapan stablecoin dan aset yang ditokenisasi baru dapat dibuat. Rilis v1.8.1 pada 16 Oktober menjadwalkan Jenner untuk testnet Chapel di BNB Smart Chain pada 29 Oktober pukul 02.30 UTC. Pengumuman sebelumnya memberi panduan bahwa peluncuran di mainnet akan berlangsung pada akhir November, tetapi waktu pastinya belum diumumkan. Standar BEP-702 yang diusulkan masih berstatus Draf dan mencakup token CAS20, sedangkan token BEP-20 yang sudah ada tidak akan terdampak. CAS20 akan menerapkan perilaku token umum dalam logika bawaan jaringan melalui precompile yang menyimpan status.

Berdasarkan BEP-702, tata kelola jaringan menunjuk administrator aktivasi melalui GovHub, kontrak penerus tata kelola BSC. Implementasi aktivasi hanya mengizinkan GovHub mengubah administrator, dan hanya administrator tersimpan yang tidak bernilai nol yang dapat mengaktifkan atau menonaktifkan fitur. Sakelar terpisah mengatur pembuatan token varian Asset, pembuatan token varian Stablecoin, dan penulisan ke registri kebijakan bersama. Setelah suatu varian diaktifkan, proses pembuatan oleh factory tidak memuat daftar persetujuan untuk masing-masing penerbit. Pembuat token menetapkan administrator awal token dan instruksi inisialisasi. Daftar putih akses awal bagi penerbit di halaman BNB Chain tidak membuktikan bahwa kode tersebut memberi lisensi secara terpisah kepada setiap penerbit.

Menonaktifkan fitur pembuatan token akan mencegah pembuatan token CAS20 baru dari varian tersebut. Token yang sudah ada tetap dapat mencetak unit tambahan berdasarkan izin yang sudah berlaku, mentransfer saldo, dan mengelola peran. Pemasangan dukungan Jenner dan pengaktifan pembuatan untuk varian yang dipilih merupakan dua tahapan peluncuran yang terpisah. Sakelar pembuatan bukan mekanisme langsung untuk memindahkan atau membekukan saldo pemegang token yang sudah ada.

Administrator token memilih kebijakan untuk operasi tertentu, dan setiap kebijakan memiliki administrator terpisah yang bertanggung jawab atas keanggotaan. Implementasi yang ditandai mensyaratkan aktivasi fitur untuk penulisan ke registri, termasuk perubahan keanggotaan dan pergantian administrator. Token tetap dapat memeriksa daftar yang sudah ada ketika penulisan ke registri dinonaktifkan. Akun yang sudah diblokir berdasarkan kebijakan transfer dapat tetap dibatasi karena administrator daftar tidak dapat menghapus akun tersebut saat penulisan ke registri dinonaktifkan. Namun, administrator bawaan token dapat mengikat token ke kebijakan lain yang sudah ada di luar sakelar penulisan ke registri, sesuai dengan izin administratif token yang masih berlaku. Perubahan keanggotaan kebijakan bersama dapat mengubah kelayakan akun untuk setiap token dan operasi yang merujuk kebijakan tersebut. Mengganti administrator aktivasi memulihkan kendali atas sakelar, tetapi tidak memperbaiki entri daftar; membuka kembali penulisan dan memperbarui keanggotaan yang diizinkan tetap merupakan tindakan terpisah.

Pencetakan, pembakaran token sendiri, penyitaan, penghentian sementara dan pemulihan transfer menggunakan peran token terpisah yang dapat diberikan kepada alamat berbeda atau dipusatkan pada satu alamat. Kewenangan aktivasi tingkat jaringan, keanggotaan dalam peran token, dan administrasi daftar kebijakan tetap merupakan izin yang berbeda, sekalipun satu organisasi memegang beberapa izin. Transfer biasa memeriksa pengirim dan penerima berdasarkan kebijakan masing-masing, sedangkan transfer yang didelegasikan juga memeriksa pelaksananya. Pencetakan menggunakan kebijakan penerima yang terpisah, sehingga izin untuk menerima unit yang baru dicetak tidak otomatis memberikan izin untuk mengirim token atau bertindak atas nama pemegang lain.

Penyitaan memungkinkan operator berwenang mengalihkan saldo yang memenuhi syarat tanpa persetujuan pemegangnya. Namun, konfigurasi bawaan melindungi setiap pemegang, sehingga pemberian peran penyitaan saja tidak membuat saldo memenuhi syarat untuk disita. Kode v1.8.1 menamai aturan pemegang tersebut SEIZE_EXEMPT_POLICY, dan otorisasi berdasarkan aturan itu melindungi akun dari penyitaan. Pengalihan biasa setelah token dibuat mensyaratkan pemeriksaan pengecualian gagal, adanya peran penyitaan, fungsi penyitaan tidak sedang dijeda, saldo mencukupi, serta tujuan yang valid dan diizinkan oleh kebijakan penerima penyitaan. Jika perlindungan tersebut terpenuhi, seizeWithMemo melewati pemeriksaan kebijakan transfer biasa dan tidak mengubah total pasokan. Pembakaran mengurangi pasokan dan, untuk pemanggilan CAS20 biasa, hanya menggunakan token milik pemanggil berdasarkan peran terpisah. Kelayakan transfer biasa tidak menentukan kelayakan penyitaan. Menghentikan sementara transfer tidak menghentikan penyitaan, yang memiliki pengaturan jeda terpisah dan tetap tunduk pada perlindungan lainnya.

Kontrol Cobalt milik Base juga memisahkan peran dan kelayakan berdasarkan standar B20. CAS20 menambahkan pertanyaan tentang bagaimana penerimaan fitur di tingkat jaringan BNB Chain akan berinteraksi dengan kontrol di tingkat token. Halaman CAS20 BNB Chain mencari penerbit untuk akses awal dan menjelaskan varian Stablecoin dan Asset. Kode bawaan yang umum mengurangi kebutuhan untuk menerapkan perilaku token yang sama secara terpisah. Namun, usulan tersebut memperingatkan bahwa cacat pada klien bawaan dapat berdampak pada beberapa token CAS20 dan memerlukan hard fork lain untuk memperbaikinya. Tanggal peluncuran mainnet saja tidak akan menjelaskan alamat mana yang memegang kewenangan aktivasi, bagaimana alamat tersebut menandatangani perubahan, atau fitur mana yang telah diaktifkan.