Saya sedang menyilangkan (cross-referencing) berkas peraturan $DUSK dengan catatan arsitektur miliknya sendiri ketika saya melihat dua nama yang muncul di dokumen berbeda dan tidak cocok seperti yang saya harapkan. Asumsi pertama saya: ini hanya inkonsistensi penamaan lintas tim, tidak ada perubahan struktural.

Setelah saya gali lebih dalam, saya menyadari bahwa ECSP sebenarnya bukan sebuah mekanisme; ECSP adalah status otorisasi—izin bagi sebuah bisnis untuk menerbitkan penawaran yang memenuhi syarat sesuai aturan crowdfunding UE. Di sisi teknis, ada kejadian serupa. XSC adalah nama untuk fungsionalitas yang terkait sekuritas di Dusk, sementara Zedger, model transaksi hibrida UTXO dan berbasis akun, adalah yang benar-benar menjalankan fungsi itu di balik layar.

Saat itulah cara berpikir saya bergeser. Otorisasi dan eksekusi biasanya dianggap satu paket, tetapi di sini keduanya jelas merupakan lapisan yang terpisah. Lisensi memberi akses hukum untuk membawa sebuah aset ke dalam pasar. Model transaksi memindahkan aset itu setelah aset tersebut sudah ada. Tidak satu pun menggantikan yang lain, dan menggabungkannya akan menyamarkan di mana letak bottleneck yang sebenarnya.

Hal yang belum saya selesaikan adalah bagaimana kedua lapisan ini tetap tersinkron ketika semuanya sudah berjalan. Jika persetujuan regulasi berjalan, tetapi penerbit tidak menstrukturkan penawaran secara spesifik terhadap Zedger, atau integrasi teknis melaju lebih cepat daripada penawaran yang sudah diotorisasi, satu sisi akhirnya menanggung beban mati bagi sisi lainnya.

Saya akan memantau penawaran nyata yang berasal di bawah ECSP, aktivitas integrasi yang merujuk Zedger bukan sekadar XSC sebagai label, serta apakah tim yang membangun dengan @Dusk menargetkan lapisan yang tepat.

Apakah memisahkan izin dari eksekusi dengan sedemikian rapi membuat sistem lebih mudah dipahami, atau apakah itu hanya menciptakan lebih banyak tempat agar koordinasi secara diam-diam bisa rusak?#dusk
$BTR
$TAC