Komitmen keandalan dependensi attestation smart contract
Sudah memikirkan ini beberapa hari karena saya pernah menambahkan dependensi pihak ketiga ke smart contract sebelumnya, dan pertanyaannya selalu mentok di hal yang sama: apa yang terjadi pada protokol saya jika dependensinya mati.
Newton mengharuskan aplikasi memvalidasi attestation BLS di dalam smart contract mereka sebelum mengeksekusi. Tanpa attestation yang valid, tidak ada eksekusi.
Itu mekanisme penegakannya dan juga dependensi yang bersifat wajib (hard dependency).
Setelah sebuah protokol menerapkan persyaratan itu ke dalam kontrak yang tidak dapat diubah (immutable), protokol tersebut telah berkomitmen bahwa jaringan operator Newton akan tersedia untuk setiap transaksi yang akan pernah diproses oleh kontrak tersebut.
Itu bukan kritik. Itu pilihan desain dengan implikasi nyata.
Protokol yang mengintegrasikan Newton tidak lagi hanya mengandalkan kode miliknya sendiri.
Protokol tersebut mengandalkan bahwa kuorum operator yang dipertaruhkan (staked) akan mengevaluasi kebijakan dan menghasilkan attestation untuk setiap transaksi secara berkelanjutan.
Whitepaper membahas sensor (censorship) melalui force-inclusion. Whitepaper tidak membahas apa yang terjadi selama degradasi nyata pada jaringan operator—bukan sensor, melainkan keterlambatan kinerja atau sebagian outage.
#newt Saya justru berpikir bahwa komitmen keandalan adalah pertanyaan yang paling penting bagi tim protokol yang menilai Newton, lebih dari sekadar fitur kepatuhan (compliance). Menambahkan dependensi ke smart contract bersifat permanen dengan cara yang berbeda dibanding menambahkan dependensi ke layanan web.
#NEWT Hal yang belum saya pahami adalah apakah ada mode degradasi yang berjalan mulus (graceful degradation)—semacam cara agar protokol bisa beralih (fall back) saat terjadi gangguan pada operator, alih-alih berhenti sepenuhnya.
#ShareYourThinking $LAB $HMSTR @NewtonProtocol $NEWT #Newt