Binance Square
CryptoMasterXY
724 Posting

CryptoMasterXY

Crypto MasterX | Precision. TA On-chain Execution Master. Repeat
Perdagangan Terbuka
Pedagang Rutin
1.8 Tahun
41 Mengikuti
89 Pengikut
647 Disukai
Posting
Portofolio
·
--
Aku membongkar skrip penebusan brankas, mencari celah untuk kabur. Tidak ada. Hanya opcode OP_CHECKSEQUENCEVERIFY dan tinggi blok yang akan tiba—baik kamu siap atau tidak. Tidak ada override multisig. Tidak ada kunci admin. Tidak ada pelepasan awal yang dipicu oracle. Saat kamu mengklik Unstake, kamu tidak sedang meminta izin. Kamu menyalakan sumbu yang membakar tepat dengan kecepatan produksi blok Bitcoin, dan tidak ada apa pun di dunia yang bisa membuatnya membakar lebih cepat. Masalahnya, pasar tidak berhenti saat sumbu itu terbakar. Enam hari memasuki masa unbonding tujuh hari, grafik mencetak candle merah 12%, dan aku tidak bisa bergerak. Bukan karena aku membeku. Tapi karena skrip brankas sudah mengunci keluarku ke sebuah timestamp yang belum tiba. Imbal hasil yang kudapat bukan bunga. Itu adalah premi yang kupungut dari menjual hakku untuk panik. Setiap basis poin dari imbal hasil itu dihargai terhadap probabilitas bahwa aku akan membutuhkan likuiditas sebelum masa timelock berakhir dan tidak akan punya cara untuk mendapatkannya. Obrolan voice pada malam itu bukan membahas harga masuk. Itu dipenuhi orang-orang yang menonton timer mereka sendiri menghitung mundur, saling bertukar screenshot dari block explorer seperti majalah ruang tunggu rumah sakit. Brankas mengamankan Bitcoinmu. Timelock mengamankan protokol. Grup chat mengamankan bagian dari dirimu yang bisa menatap pisau jatuh dan tidak mengambilnya sebelum hitung mundur berakhir. Aku tidak mempelajarinya dari whitepaper. Aku mendapatkannya dari seseorang asing yang mengetik "tarik napas, block 847,032 akan datang entah bagaimana pun" ke dalam chat yang hampir tidak kuikuti. Skrip penebusannya transparan. Penebusan emosional di sisi lain dari timelock tidak. #baby $BABY @babylonlabs_io $1000RATS $KOMA
Aku membongkar skrip penebusan brankas, mencari celah untuk kabur. Tidak ada. Hanya opcode OP_CHECKSEQUENCEVERIFY dan tinggi blok yang akan tiba—baik kamu siap atau tidak. Tidak ada override multisig. Tidak ada kunci admin. Tidak ada pelepasan awal yang dipicu oracle.

Saat kamu mengklik Unstake, kamu tidak sedang meminta izin. Kamu menyalakan sumbu yang membakar tepat dengan kecepatan produksi blok Bitcoin, dan tidak ada apa pun di dunia yang bisa membuatnya membakar lebih cepat.

Masalahnya, pasar tidak berhenti saat sumbu itu terbakar. Enam hari memasuki masa unbonding tujuh hari, grafik mencetak candle merah 12%, dan aku tidak bisa bergerak. Bukan karena aku membeku. Tapi karena skrip brankas sudah mengunci keluarku ke sebuah timestamp yang belum tiba. Imbal hasil yang kudapat bukan bunga. Itu adalah premi yang kupungut dari menjual hakku untuk panik.

Setiap basis poin dari imbal hasil itu dihargai terhadap probabilitas bahwa aku akan membutuhkan likuiditas sebelum masa timelock berakhir dan tidak akan punya cara untuk mendapatkannya.

Obrolan voice pada malam itu bukan membahas harga masuk. Itu dipenuhi orang-orang yang menonton timer mereka sendiri menghitung mundur, saling bertukar screenshot dari block explorer seperti majalah ruang tunggu rumah sakit.

Brankas mengamankan Bitcoinmu. Timelock mengamankan protokol.

Grup chat mengamankan bagian dari dirimu yang bisa menatap pisau jatuh dan tidak mengambilnya sebelum hitung mundur berakhir. Aku tidak mempelajarinya dari whitepaper. Aku mendapatkannya dari seseorang asing yang mengetik "tarik napas, block 847,032 akan datang entah bagaimana pun" ke dalam chat yang hampir tidak kuikuti.

Skrip penebusannya transparan. Penebusan emosional di sisi lain dari timelock tidak.

#baby $BABY @BabylonLabs_io $1000RATS $KOMA
Saya tidak mencari kata "trust" di dokumen whitepaper. Saya mencari off-ramp, human override, baris kode yang menjeda eksekusi saat seseorang menyadari telah membuat kesalahan. Itu tidak ada. Skema EOTS adalah cermin tanpa ampun. Saya menandatangani sebuah blok dengan jujur, lalu menandatangani yang bertentangan hanya untuk melihat matematika berjalan. Tanda tangan kedua memecahkan yang pertama dan menumpahkan kunci privat ke atas rantai seperti pengakuan yang tidak Anda sadari sedang Anda tulis. Tidak ada hakim. Tidak ada pemungutan suara. Hanya kurva yang melakukan apa yang memang dilakukan kurva. Babylon tidak membangun mekanisme hukuman. Babylon membangun mesin potret-diri. Setiap validator yang menandatangani dengan benar meninggalkan bukan bukti kejujuran, melainkan ketiadaan kehancuran diri. Kunci Anda tetap rahasia hanya selama Anda tetap selaras dengan kebenaran yang Anda tandatangani pertama kali. Itulah pembalikan yang belum tahu cara diberi harga oleh pasar. Rantai lain meminta Anda untuk mempercayai sebuah komite. Babylon meminta Anda untuk bertahan dari versi diri Anda yang mungkin runtuh saat ada red candle dan menekan kirim. Satu-satunya kerentanan yang tersisa bukanlah yang kriptografis. Itu adalah momen saat Anda berhenti percaya bahwa cermin itu akan tetap berdiri, dan Anda menjadi penyerang yang justru ingin diungkap oleh protokol. Obrolan suara komunitas tidak mengamankan jaringan. Obrolan itu mengamankan jeda antara impuls dan tindakan. Brankas menyimpan Bitcoin Anda. Matematika menyimpan para validator. Obrolan grup menyimpan versi Anda yang masih bersedia menghadapi cermin besok. Saya tidak tahu apakah Babylon menang. Saya tahu Babylon tidak meminta kepercayaan. Babylon meminta ketahanan, dan ketahanan adalah satu-satunya alpha yang tidak bisa dipanen. @babylonlabs_io $BABY #baby $KOMA $SNXXB #baby
Saya tidak mencari kata "trust" di dokumen whitepaper. Saya mencari off-ramp, human override, baris kode yang menjeda eksekusi saat seseorang menyadari telah membuat kesalahan. Itu tidak ada.

Skema EOTS adalah cermin tanpa ampun. Saya menandatangani sebuah blok dengan jujur, lalu menandatangani yang bertentangan hanya untuk melihat matematika berjalan. Tanda tangan kedua memecahkan yang pertama dan menumpahkan kunci privat ke atas rantai seperti pengakuan yang tidak Anda sadari sedang Anda tulis. Tidak ada hakim. Tidak ada pemungutan suara. Hanya kurva yang melakukan apa yang memang dilakukan kurva.

Babylon tidak membangun mekanisme hukuman. Babylon membangun mesin potret-diri. Setiap validator yang menandatangani dengan benar meninggalkan bukan bukti kejujuran, melainkan ketiadaan kehancuran diri. Kunci Anda tetap rahasia hanya selama Anda tetap selaras dengan kebenaran yang Anda tandatangani pertama kali.

Itulah pembalikan yang belum tahu cara diberi harga oleh pasar. Rantai lain meminta Anda untuk mempercayai sebuah komite. Babylon meminta Anda untuk bertahan dari versi diri Anda yang mungkin runtuh saat ada red candle dan menekan kirim. Satu-satunya kerentanan yang tersisa bukanlah yang kriptografis. Itu adalah momen saat Anda berhenti percaya bahwa cermin itu akan tetap berdiri, dan Anda menjadi penyerang yang justru ingin diungkap oleh protokol.

Obrolan suara komunitas tidak mengamankan jaringan. Obrolan itu mengamankan jeda antara impuls dan tindakan. Brankas menyimpan Bitcoin Anda. Matematika menyimpan para validator. Obrolan grup menyimpan versi Anda yang masih bersedia menghadapi cermin besok. Saya tidak tahu apakah Babylon menang. Saya tahu Babylon tidak meminta kepercayaan. Babylon meminta ketahanan, dan ketahanan adalah satu-satunya alpha yang tidak bisa dipanen.

@BabylonLabs_io $BABY #baby $KOMA $SNXXB
#baby
Saya mencari kata "trust" dalam whitepaper Babylon empat kali. Saya menemukannya persis nol kali. Angka itu membuat saya tidak bisa tidur. Bukan karena trust tidak ada dalam protokol. Tapi karena ia telah digantikan oleh sesuatu yang belum siap saya namai. Saya menelusuri skema tanda tangan EOTS pada penyedia finalitas testnet yang sengaja saya rusak. Tanda tangani sekali dengan jujur, dan kuncinya tetap tersembunyi. Tanda tangani dua kali pada blok yang saling bertentangan, dan matematika mempublikasikan kunci privat Anda ke jaringan. Tidak ada pengadilan. Tidak ada pemungutan suara tata kelola. Hukumannya tidak memerlukan hakim karena kebohongannya membawa algojo sendiri. Saya menjalankan simulasi sambil berharap menemukan ambang batas, masa tenggang, atau pengambil alihan dari manusia. Tidak ada. Ekonomilah yang menjerat saya. Validator yang double-signing kehilangan bonded stake ditambah BTC yang disita (slashed). Tapi itu biaya untuk gagal melakukan serangan. Biaya untuk meluncurkannya adalah harus lebih cepat daripada timestamp Bitcoin terlebih dahulu, yang berarti menyusun ulang sebuah buku besar senilai triliunan dolar sebelum ekstraksi tanda tangan bahkan terpicu. Anda tidak disita hanya karena mencoba. Anda disita karena mencoba dan kalah. Itulah bagian yang tidak bisa berhenti saya pikirkan. Babylon tidak mencegah Anda untuk bersikap tidak jujur. Ia membuat ketidakjujuran secara struktural identik dengan pengakuan begitu bukti kerja Bitcoin menolak mengikuti fork Anda. Kebanyakan rantai menjual kepada Anda trust dari sebuah komite. Babylon menjual trust dalam sebuah aksioma: jika Anda curang, matematika akan mengungkap Anda sebelum ada manusia yang menyadarinya. Itu bukan keamanan. Itu determinisme. Saya tidak tahu apakah pasar sudah menghargainya. Saya tahu bahwa setiap rantai lain meminta Anda untuk percaya. Babylon meminta Anda untuk menghitung. Dan menghitung lebih murah daripada percaya—hingga suatu saat tidak lagi. #baby $BABY @babylonlabs_io $COTI $UAI
Saya mencari kata "trust" dalam whitepaper Babylon empat kali. Saya menemukannya persis nol kali.

Angka itu membuat saya tidak bisa tidur. Bukan karena trust tidak ada dalam protokol. Tapi karena ia telah digantikan oleh sesuatu yang belum siap saya namai.

Saya menelusuri skema tanda tangan EOTS pada penyedia finalitas testnet yang sengaja saya rusak. Tanda tangani sekali dengan jujur, dan kuncinya tetap tersembunyi. Tanda tangani dua kali pada blok yang saling bertentangan, dan matematika mempublikasikan kunci privat Anda ke jaringan. Tidak ada pengadilan. Tidak ada pemungutan suara tata kelola. Hukumannya tidak memerlukan hakim karena kebohongannya membawa algojo sendiri.

Saya menjalankan simulasi sambil berharap menemukan ambang batas, masa tenggang, atau pengambil alihan dari manusia. Tidak ada. Ekonomilah yang menjerat saya.

Validator yang double-signing kehilangan bonded stake ditambah BTC yang disita (slashed). Tapi itu biaya untuk gagal melakukan serangan. Biaya untuk meluncurkannya adalah harus lebih cepat daripada timestamp Bitcoin terlebih dahulu, yang berarti menyusun ulang sebuah buku besar senilai triliunan dolar sebelum ekstraksi tanda tangan bahkan terpicu.

Anda tidak disita hanya karena mencoba. Anda disita karena mencoba dan kalah.
Itulah bagian yang tidak bisa berhenti saya pikirkan. Babylon tidak mencegah Anda untuk bersikap tidak jujur. Ia membuat ketidakjujuran secara struktural identik dengan pengakuan begitu bukti kerja Bitcoin menolak mengikuti fork Anda.

Kebanyakan rantai menjual kepada Anda trust dari sebuah komite. Babylon menjual trust dalam sebuah aksioma: jika Anda curang, matematika akan mengungkap Anda sebelum ada manusia yang menyadarinya. Itu bukan keamanan. Itu determinisme.

Saya tidak tahu apakah pasar sudah menghargainya. Saya tahu bahwa setiap rantai lain meminta Anda untuk percaya. Babylon meminta Anda untuk menghitung. Dan menghitung lebih murah daripada percaya—hingga suatu saat tidak lagi.

#baby $BABY @BabylonLabs_io $COTI $UAI
Saya ingin tahu apa yang terjadi pada jeda antara saat real backing penyedia finalitas berubah dan ketika protokol mengakui bahwa perubahan itu sudah terjadi. Jadi saya menelusuri bagaimana modul x/epoching di Babylon benar-benar memproses delegasi baru. Pesan staking dan unstaking tidak dieksekusi seketika. Mereka mengantri selama panjang satu epoch penuh, lalu diproses dalam satu batch di batasnya. Sampai batas itu tercapai, kekuatan voting finalitas rantai masih mencerminkan snapshot lama, bukan yang terbaru. Penyedia finalitas bisa saja kehilangan delegasi secara real time, bisa secara ekonomis mengosongkan diri di tengah epoch, namun tetap melakukan voting dengan bobot yang dimilikinya sebelum siapa pun menarik. Ini bukan bug. Ini adalah tradeoff untuk membatch ribuan delegasi yang didukung BTC menjadi satu penyelesaian alih-alih memproses semuanya secara individual. Tetapi artinya dukungan keamanan kripto-ekonomis untuk sebuah blok tertentu bukanlah keamanan yang ada saat ini. Itu adalah keamanan yang ada pada checkpoint terakhir, dibawa ke depan atas dasar kepercayaan bahwa tidak ada perubahan material di antaranya. Saya terus membandingkannya dengan cara kerja jalur kredit. Limit Anda tidak langsung berubah saat penghasilan Anda berubah. Limit itu diperbarui pada satu siklus, dan di antaranya, bank memperpanjang kepercayaan berdasarkan angka yang sudah sedikit tidak tepat. Babylon melakukan hal yang sama dengan bobot Bitcoin, hanya saja dengan kriptografi yang lebih baik yang melapisi ketidakakuratan itu. Saya tidak berpikir ini merusak model. Fast unbonding, kurang lebih dua hari, membuat jendela tersebut tetap pendek dibandingkan rantai PoS pada umumnya. Tapi pendek itu tidak nol, dan bagian yang perlu diawasi bukanlah harga token. Yang perlu diperhatikan adalah seberapa lebar jendela epoch itu ketika set validator terus bertambah ukurannya. $BABY @babylonlabs_io #baby $ON $BTC
Saya ingin tahu apa yang terjadi pada jeda antara saat real backing penyedia finalitas berubah dan ketika protokol mengakui bahwa perubahan itu sudah terjadi. Jadi saya menelusuri bagaimana modul x/epoching di Babylon benar-benar memproses delegasi baru.

Pesan staking dan unstaking tidak dieksekusi seketika. Mereka mengantri selama panjang satu epoch penuh, lalu diproses dalam satu batch di batasnya. Sampai batas itu tercapai, kekuatan voting finalitas rantai masih mencerminkan snapshot lama, bukan yang terbaru. Penyedia finalitas bisa saja kehilangan delegasi secara real time, bisa secara ekonomis mengosongkan diri di tengah epoch, namun tetap melakukan voting dengan bobot yang dimilikinya sebelum siapa pun menarik.

Ini bukan bug. Ini adalah tradeoff untuk membatch ribuan delegasi yang didukung BTC menjadi satu penyelesaian alih-alih memproses semuanya secara individual. Tetapi artinya dukungan keamanan kripto-ekonomis untuk sebuah blok tertentu bukanlah keamanan yang ada saat ini. Itu adalah keamanan yang ada pada checkpoint terakhir, dibawa ke depan atas dasar kepercayaan bahwa tidak ada perubahan material di antaranya.

Saya terus membandingkannya dengan cara kerja jalur kredit. Limit Anda tidak langsung berubah saat penghasilan Anda berubah. Limit itu diperbarui pada satu siklus, dan di antaranya, bank memperpanjang kepercayaan berdasarkan angka yang sudah sedikit tidak tepat. Babylon melakukan hal yang sama dengan bobot Bitcoin, hanya saja dengan kriptografi yang lebih baik yang melapisi ketidakakuratan itu.

Saya tidak berpikir ini merusak model. Fast unbonding, kurang lebih dua hari, membuat jendela tersebut tetap pendek dibandingkan rantai PoS pada umumnya. Tapi pendek itu tidak nol, dan bagian yang perlu diawasi bukanlah harga token. Yang perlu diperhatikan adalah seberapa lebar jendela epoch itu ketika set validator terus bertambah ukurannya.

$BABY @BabylonLabs_io #baby $ON $BTC
Saya mengira komite perjanjian itu hanya formalitas, semacam multisig yang dibutuhkan setiap protokol staking Bitcoin dan tak ada yang benar-benar membaca kodenya. Saya hanya berubah pikiran setelah menelusuri apa yang terjadi ketika seorang validator mencoba melakukan unbond lebih awal. Tidak ada antrean unbond seperti yang orang bayangkan. Saat Anda melakukan staking, Anda tidak menandatangani janji untuk menunggu. Anda menandatangani transaksi keluar itu sendiri, terlebih dahulu, dengan penguncian waktu (timelocked), yang dipegang oleh komite perjanjian sebelum BTC Anda bahkan bergerak menuju validator. Komite itu tidak memutuskan apakah Anda mendapatkan Bitcoin Anda kembali. Ia memegang transaksi yang sudah memutuskan, dan hanya menunggu jam yang ditentukan oleh tanda tangan. Rincian tunggal itu mengubah apa sebenarnya komite tersebut. Komite itu bukan badan tata kelola dengan kebijaksanaan. Ia adalah notaris untuk keputusan yang sudah Anda buat sendiri. Tugasnya seluruhnya adalah menolak untuk memiliki opini. Begitu seorang anggota perjanjian mulai menilai apakah keluarnya Anda sudah adil, desainnya sudah gagal, karena keadilan seharusnya diputuskan pada saat tanda tangan, bukan pada saat penebusan. Saya terus memikirkan betapa tidak biasa hal itu di luar kode. Hampir setiap institusi yang berurusan dengan kita—bank, tuan tanah, pengadilan—memiliki hak untuk menafsirkan ulang kasus Anda nanti. Komite Babylon dibangun supaya tidak punya kasus yang bisa ditafsirkan ulang. Itu sudah ditutup rapat sejak ditandatangani. Saya tidak yakin itu membuat early exit terasa tanpa rasa sakit. Itu berarti rasa sakit sudah dihargakan sebelum Anda staking, bukan dinegosiasikan setelahnya. Sebuah struktur di mana percakapan tersulit sudah terjadi, diam-diam, pada hari Anda mengklik konfirmasi. $BABY @babylonlabs_io #baby $COTI $ON
Saya mengira komite perjanjian itu hanya formalitas, semacam multisig yang dibutuhkan setiap protokol staking Bitcoin dan tak ada yang benar-benar membaca kodenya. Saya hanya berubah pikiran setelah menelusuri apa yang terjadi ketika seorang validator mencoba melakukan unbond lebih awal.

Tidak ada antrean unbond seperti yang orang bayangkan. Saat Anda melakukan staking, Anda tidak menandatangani janji untuk menunggu. Anda menandatangani transaksi keluar itu sendiri, terlebih dahulu, dengan penguncian waktu (timelocked), yang dipegang oleh komite perjanjian sebelum BTC Anda bahkan bergerak menuju validator. Komite itu tidak memutuskan apakah Anda mendapatkan Bitcoin Anda kembali. Ia memegang transaksi yang sudah memutuskan, dan hanya menunggu jam yang ditentukan oleh tanda tangan.

Rincian tunggal itu mengubah apa sebenarnya komite tersebut. Komite itu bukan badan tata kelola dengan kebijaksanaan. Ia adalah notaris untuk keputusan yang sudah Anda buat sendiri. Tugasnya seluruhnya adalah menolak untuk memiliki opini. Begitu seorang anggota perjanjian mulai menilai apakah keluarnya Anda sudah adil, desainnya sudah gagal, karena keadilan seharusnya diputuskan pada saat tanda tangan, bukan pada saat penebusan.

Saya terus memikirkan betapa tidak biasa hal itu di luar kode. Hampir setiap institusi yang berurusan dengan kita—bank, tuan tanah, pengadilan—memiliki hak untuk menafsirkan ulang kasus Anda nanti. Komite Babylon dibangun supaya tidak punya kasus yang bisa ditafsirkan ulang. Itu sudah ditutup rapat sejak ditandatangani.

Saya tidak yakin itu membuat early exit terasa tanpa rasa sakit. Itu berarti rasa sakit sudah dihargakan sebelum Anda staking, bukan dinegosiasikan setelahnya. Sebuah struktur di mana percakapan tersulit sudah terjadi, diam-diam, pada hari Anda mengklik konfirmasi.

$BABY @BabylonLabs_io #baby $COTI $ON
Saya menghabiskan satu sore untuk mencoba menjawab sebuah pertanyaan yang aneh. Jika sebuah rollup berbohong tentang riwayatnya sendiri, sejauh apa Anda harus menggali untuk menangkapnya. Untuk kebanyakan rantai, jawaban yang jujur membuat tidak nyaman. Anda perlu mempercayai siapa pun yang masih mengawasinya. Lalu saya menelusuri bagaimana protokol pencatatan waktu (timestamping) Babylon benar-benar bekerja, per blok, pada sebuah rantai testnet yang saya kendalikan. Dari waktu ke waktu, keadaan rantai tersebut di-checkpoint-kan ke dalam sebuah blok Bitcoin nyata, bukan ringkasan, bukan referensi, melainkan komitmen sungguhan yang dimeteraikan oleh proof of work yang sama yang mengamankan sejarah senilai satu triliun dolar. Setelah checkpoint itu ada, mengubah ulang masa lalu rollup berarti mengubah ulang masa lalu Bitcoin terlebih dahulu. Tak ada yang mengubah ulang masa lalu Bitcoin. Bukan karena dilarang. Karena biaya untuk mencobanya adalah biaya peradaban. Saya terus membandingkannya dengan sesuatu yang sangat biasa. Kebanyakan dari apa yang kita sebut sebagai ingatan, dalam sebuah pernikahan, pertemanan, atau kesepakatan bisnis, itu bisa dinegosiasikan. Dua orang bisa mengingat tahun yang sama dengan cara berbeda dan tidak ada yang secara teknis berbohong. Yang dibangun Babylon adalah kebalikan dari jenis ingatan itu. Versi masa lalu yang berhenti bisa dinegosiasikan begitu cukup banyak proof of work diletakkan di atasnya. Menurut saya itulah yang terlewat ketika orang menyebut ini sekadar permainan restaking lainnya. Ini bukan menyewa keamanan. Ini menyewa kepastian (permanence), meminjam satu-satunya ledger yang tidak pernah, sekalipun di bawah tekanan, sepakat untuk melupakan sesuatu. Saya belum tahu apakah pasar memberi harga pada kepastian dengan benar. Saya tahu ini satu-satunya komoditas di sini yang berkompounding, bukan merosot. $BABY @babylonlabs_io #baby $EUL $ESP
Saya menghabiskan satu sore untuk mencoba menjawab sebuah pertanyaan yang aneh. Jika sebuah rollup berbohong tentang riwayatnya sendiri, sejauh apa Anda harus menggali untuk menangkapnya. Untuk kebanyakan rantai, jawaban yang jujur membuat tidak nyaman. Anda perlu mempercayai siapa pun yang masih mengawasinya.

Lalu saya menelusuri bagaimana protokol pencatatan waktu (timestamping) Babylon benar-benar bekerja, per blok, pada sebuah rantai testnet yang saya kendalikan. Dari waktu ke waktu, keadaan rantai tersebut di-checkpoint-kan ke dalam sebuah blok Bitcoin nyata, bukan ringkasan, bukan referensi, melainkan komitmen sungguhan yang dimeteraikan oleh proof of work yang sama yang mengamankan sejarah senilai satu triliun dolar. Setelah checkpoint itu ada, mengubah ulang masa lalu rollup berarti mengubah ulang masa lalu Bitcoin terlebih dahulu. Tak ada yang mengubah ulang masa lalu Bitcoin. Bukan karena dilarang. Karena biaya untuk mencobanya adalah biaya peradaban.

Saya terus membandingkannya dengan sesuatu yang sangat biasa. Kebanyakan dari apa yang kita sebut sebagai ingatan, dalam sebuah pernikahan, pertemanan, atau kesepakatan bisnis, itu bisa dinegosiasikan. Dua orang bisa mengingat tahun yang sama dengan cara berbeda dan tidak ada yang secara teknis berbohong. Yang dibangun Babylon adalah kebalikan dari jenis ingatan itu. Versi masa lalu yang berhenti bisa dinegosiasikan begitu cukup banyak proof of work diletakkan di atasnya.

Menurut saya itulah yang terlewat ketika orang menyebut ini sekadar permainan restaking lainnya. Ini bukan menyewa keamanan. Ini menyewa kepastian (permanence), meminjam satu-satunya ledger yang tidak pernah, sekalipun di bawah tekanan, sepakat untuk melupakan sesuatu.

Saya belum tahu apakah pasar memberi harga pada kepastian dengan benar. Saya tahu ini satu-satunya komoditas di sini yang berkompounding, bukan merosot.

$BABY @BabylonLabs_io #baby $EUL $ESP
Saya ingin menjelaskan sesuatu yang kebanyakan orang abaikan tanpa sadar, karena sekilas tampak seperti infrastruktur kripto biasa. Itu tidak. Saya menelusuri bagaimana skema Babylon Extractable One-Time Signature sebenarnya bekerja ketika terjadi penandatangan ganda—bukan dengan membacanya, melainkan dengan mensimulasikannya terhadap penyedia finalitas uji. Tanda tangani sekali dengan jujur, dan tanda tangan tidak mengungkap apa pun selain yang memang ia otorisasi. Tanda tangani dua kali pada blok yang saling bertentangan, dan matematikanya sendiri akan merekonstruksi kunci privat Anda. Bukan hukuman yang dipaksakan oleh tata kelola. Bukan juga suara dari validator. Ketidakjujuran yang terjadi justru “mengambil” hukumannya dari dalam kebohongan itu. Saya terus berpikir tentang betapa jarangnya hal seperti itu ada di tempat lain—di dalam kode maupun dalam kehidupan. Kebanyakan sistem kepercayaan akan menangkap Anda setelah kejadian, lewat saksi, buku besar, atau skor reputasi yang dikelola orang lain. Yang ini tidak butuh saksi. Pengkhianatan secara struktural identik dengan pengakuan. Anda tidak bisa curang dengan tenang, karena “ketenangan” itulah satu-satunya hal yang menjaga Anda aman, dan begitu Anda melanggarnya, Anda telah menyerahkan bukti itu sendiri. Itulah bagian yang layak direnungkan lebih lama daripada sebuah bagan. Kita menghabiskan begitu banyak kehidupan sehari-hari untuk menegosiasikan kepercayaan melalui janji yang tidak bisa kita verifikasi, kata pasangan, alasan rekan kerja, atau teman yang mengatakan kali ini berbeda. Babylon mengodekan satu versi kepercayaan yang tidak pernah bergantung pada orang lain yang harus percaya pada Anda. Itu bergantung pada Anda untuk tidak perlu berbohong dua kali. Saya tidak yakin itu membuat BABY kebal terhadap volatilitas. Ia membuat model keamanannya sesuatu yang lebih jarang daripada sebuah fitur. Sebuah struktur di mana kejujuran tidak menanggung biaya apa pun, sementara ketidakjujuran menanggung semuanya—bukan karena penegakan, melainkan karena desain. $BABY @babylonlabs_io #baby $EUL $QI
Saya ingin menjelaskan sesuatu yang kebanyakan orang abaikan tanpa sadar, karena sekilas tampak seperti infrastruktur kripto biasa. Itu tidak.

Saya menelusuri bagaimana skema Babylon Extractable One-Time Signature sebenarnya bekerja ketika terjadi penandatangan ganda—bukan dengan membacanya, melainkan dengan mensimulasikannya terhadap penyedia finalitas uji. Tanda tangani sekali dengan jujur, dan tanda tangan tidak mengungkap apa pun selain yang memang ia otorisasi.

Tanda tangani dua kali pada blok yang saling bertentangan, dan matematikanya sendiri akan merekonstruksi kunci privat Anda. Bukan hukuman yang dipaksakan oleh tata kelola. Bukan juga suara dari validator. Ketidakjujuran yang terjadi justru “mengambil” hukumannya dari dalam kebohongan itu.

Saya terus berpikir tentang betapa jarangnya hal seperti itu ada di tempat lain—di dalam kode maupun dalam kehidupan. Kebanyakan sistem kepercayaan akan menangkap Anda setelah kejadian, lewat saksi, buku besar, atau skor reputasi yang dikelola orang lain. Yang ini tidak butuh saksi. Pengkhianatan secara struktural identik dengan pengakuan. Anda tidak bisa curang dengan tenang, karena “ketenangan” itulah satu-satunya hal yang menjaga Anda aman, dan begitu Anda melanggarnya, Anda telah menyerahkan bukti itu sendiri.

Itulah bagian yang layak direnungkan lebih lama daripada sebuah bagan. Kita menghabiskan begitu banyak kehidupan sehari-hari untuk menegosiasikan kepercayaan melalui janji yang tidak bisa kita verifikasi, kata pasangan, alasan rekan kerja, atau teman yang mengatakan kali ini berbeda. Babylon mengodekan satu versi kepercayaan yang tidak pernah bergantung pada orang lain yang harus percaya pada Anda. Itu bergantung pada Anda untuk tidak perlu berbohong dua kali.

Saya tidak yakin itu membuat BABY kebal terhadap volatilitas. Ia membuat model keamanannya sesuatu yang lebih jarang daripada sebuah fitur. Sebuah struktur di mana kejujuran tidak menanggung biaya apa pun, sementara ketidakjujuran menanggung semuanya—bukan karena penegakan, melainkan karena desain.

$BABY @BabylonLabs_io #baby $EUL $QI
Saya dulu mengira kekuatan terbesar Bitcoin juga sekaligus batasnya. Ia tidak bergerak. Ia tidak menghitung apa pun. Ia hanya diam di sana, sempurna dan siaga, sementara setiap rantai lain mencari cara agar modal bisa bekerja. Lalu saya melihat apa yang sebenarnya dilakukan Babylon, dan saya sadar saya selama ini keliru. Babylon tidak meminta Bitcoin untuk berubah. Babylon tidak membungkusnya, tidak menjembatkannya, dan tidak menyerahkannya ke kustodian yang menjanjikan untuk mengembalikannya. Babylon memakai scripting milik Bitcoin sendiri — timelock, transaksi unbonding yang telah ditandatangani sebelumnya, dan kondisi slashing yang diberlakukan melalui Extractable One-Time Signatures — sehingga jika penyedia finalitas pernah melakukan double-sign, bukti pelanggarannya dituliskan dalam kriptografi yang sama yang mengamankan koin itu sendiri. Tidak ada pihak ketiga tepercaya yang pernah memegang kunci. Tidak ada BTC sintetis yang mengapung dan berpura-pura menjadi yang asli. Saya pikir itulah yang banyak orang salah pahami di sini. Mereka melihat “staking” dan menganggap itu hanya satu lagi wrapper imbal hasil. Yang sebenarnya terjadi adalah finalitas Bitcoin — keamanan paling sulit, paling lambat, dan paling konservatif di industri ini — disewakan kepada jaringan Proof-of-Stake yang sebelumnya tak pernah bisa membeli tingkat kepercayaan seperti itu dengan cara mereka sendiri. Babylon menyebutnya Bitcoin Supercharged Networks. Saya menyebutnya menyewakan kesabaran. BABY ada di bawah semuanya — bukan sebagai dekorasi, tetapi sebagai validator token tempat staker menaruh jaminan untuk menjalankan rantai Genesis, serta control plane yang mengoordinasikan penyedia finalitas mana yang dipercaya dan mana yang di-slash. Biaya mengalir ke staker BABY. Tata kelola menentukan jaringan mana saja yang memenuhi syarat untuk keamanan berbasis BTC. Ini seperti urusan plumbing, tetapi plumbing dengan konsekuensi. Saya tidak mengira maksimalisme Bitcoin dan komposabilitas Proof-of-Stake suatu hari bisa berjabat tangan. Babylon adalah jabat tangannya. Dan ketika miliaran dolar dalam native BTC mulai duduk di dalam jabat tangan itu, bukan sebagai token wrapped di suatu jembatan di tempat lain, saya pikir pertanyaannya berubah dari “apakah ini aman” menjadi “kenapa Anda mengamankan rantai PoS dengan cara lain.” #baby $BABY @babylonlabs_io #baby $BABY
Saya dulu mengira kekuatan terbesar Bitcoin juga sekaligus batasnya.

Ia tidak bergerak. Ia tidak menghitung apa pun. Ia hanya diam di sana, sempurna dan siaga, sementara setiap rantai lain mencari cara agar modal bisa bekerja.

Lalu saya melihat apa yang sebenarnya dilakukan Babylon, dan saya sadar saya selama ini keliru.

Babylon tidak meminta Bitcoin untuk berubah. Babylon tidak membungkusnya, tidak menjembatkannya, dan tidak menyerahkannya ke kustodian yang menjanjikan untuk mengembalikannya.

Babylon memakai scripting milik Bitcoin sendiri — timelock, transaksi unbonding yang telah ditandatangani sebelumnya, dan kondisi slashing yang diberlakukan melalui Extractable One-Time Signatures — sehingga jika penyedia finalitas pernah melakukan double-sign, bukti pelanggarannya dituliskan dalam kriptografi yang sama yang mengamankan koin itu sendiri. Tidak ada pihak ketiga tepercaya yang pernah memegang kunci.

Tidak ada BTC sintetis yang mengapung dan berpura-pura menjadi yang asli.

Saya pikir itulah yang banyak orang salah pahami di sini.

Mereka melihat “staking” dan menganggap itu hanya satu lagi wrapper imbal hasil. Yang sebenarnya terjadi adalah finalitas Bitcoin — keamanan paling sulit, paling lambat, dan paling konservatif di industri ini — disewakan kepada jaringan Proof-of-Stake yang sebelumnya tak pernah bisa membeli tingkat kepercayaan seperti itu dengan cara mereka sendiri.

Babylon menyebutnya Bitcoin Supercharged Networks. Saya menyebutnya menyewakan kesabaran.

BABY ada di bawah semuanya — bukan sebagai dekorasi, tetapi sebagai validator token tempat staker menaruh jaminan untuk menjalankan rantai Genesis, serta control plane yang mengoordinasikan penyedia finalitas mana yang dipercaya dan mana yang di-slash.

Biaya mengalir ke staker BABY.

Tata kelola menentukan jaringan mana saja yang memenuhi syarat untuk keamanan berbasis BTC. Ini seperti urusan plumbing, tetapi plumbing dengan konsekuensi.

Saya tidak mengira maksimalisme Bitcoin dan komposabilitas Proof-of-Stake suatu hari bisa berjabat tangan. Babylon adalah jabat tangannya.

Dan ketika miliaran dolar dalam native BTC mulai duduk di dalam jabat tangan itu, bukan sebagai token wrapped di suatu jembatan di tempat lain, saya pikir pertanyaannya berubah dari “apakah ini aman” menjadi “kenapa Anda mengamankan rantai PoS dengan cara lain.”

#baby $BABY @BabylonLabs_io

#baby $BABY
Artikel
Jawaban Newton untuk DoS Bukanlah "Tunggu." Melainkan "Ganti Aturannya." Saya Memeriksa Apa yang Tertulis di Tanda Terima.Setiap sistem kepatuhan harus memutuskan apa yang terjadi saat sistem berada di bawah tekanan—ketika operator kewalahan, atau lonjakan permintaan mengancam menghambat evaluasi. Kebanyakan sistem menjawab pertanyaan itu dengan throughput yang menurun: semuanya menjadi lebih lambat, tetapi aturannya tetap sama. Litepaper Newton menjelaskan jawaban yang berbeda. Tindakan mitigasi yang disebutkan untuk kondisi penolakan layanan (denial-of-service) mencakup menjalankan beberapa klaster operator, percobaan ulang yang dibatasi laju (rate-limited retries)—serta kebijakan fallback, dengan contoh spesifik berupa batas transaksi yang lebih rendah.

Jawaban Newton untuk DoS Bukanlah "Tunggu." Melainkan "Ganti Aturannya." Saya Memeriksa Apa yang Tertulis di Tanda Terima.

Setiap sistem kepatuhan harus memutuskan apa yang terjadi saat sistem berada di bawah tekanan—ketika operator kewalahan, atau lonjakan permintaan mengancam menghambat evaluasi. Kebanyakan sistem menjawab pertanyaan itu dengan throughput yang menurun: semuanya menjadi lebih lambat, tetapi aturannya tetap sama. Litepaper Newton menjelaskan jawaban yang berbeda. Tindakan mitigasi yang disebutkan untuk kondisi penolakan layanan (denial-of-service) mencakup menjalankan beberapa klaster operator, percobaan ulang yang dibatasi laju (rate-limited retries)—serta kebijakan fallback, dengan contoh spesifik berupa batas transaksi yang lebih rendah.
Saya dulu memperlakukan "validator Newton" sebagai satu kelompok dengan satu model keamanan. Namun itu tidak demikian, begitu Anda menanyakan siapa yang benar-benar mendukung tiap peran. Rollup Keystore milik Newton, bagian yang menyimpan dan memperbarui izin, diamankan oleh validator yang mempertaruhkan NEWT secara langsung melalui delegated proof-of-stake. Tapi litepaper menjelaskan peran terpisah, validasi kebijakan (policy validation), yang dilakukan oleh jaringan operator terdesentralisasi yang diamankan oleh Ethereum restaking, bukan sama sekali oleh staking NEWT. Itulah bagian yang sebelumnya belum saya pisahkan. "Validator Newton" terdengar seperti satu kelompok orang yang melakukan satu pekerjaan dengan jaminan keamanan yang sama. Padahal, ini sebenarnya dua peran yang berbeda dengan dua pihak pendukung ekonomi yang berbeda. Validator rollup mempertaruhkan NEWT untuk mengamankan penyimpanan izin dan integritas eksekusi. Operator kebijakan—yang mengevaluasi transaksi berdasarkan logika kebijakan Rego atau WASM—didukung oleh ETH yang di-restake. Mereka meminjam keamanan validator Ethereum yang sudah ada, bukan membangun aset yang dipertaruhkan baru untuk pekerjaan spesifik tersebut. Jadi, keamanan sistem ini bukan satu angka saja; ada dua, dan keduanya tidak bergerak bersama. Sebuah kumpulan validator yang dipertaruhkan NEWT hanya seaman nilai pasar NEWT dan distribusinya. Kumpulan operator yang di-restake ETH mewarisi keamanan dari basis validator yang jauh lebih besar dan sudah mapan. Kenaikan penurunan harga NEWT akan melemahkan keamanan rollup tanpa harus menyentuh keamanan validasi kebijakan. Sebaliknya, kegagalan yang spesifik untuk restaking tidak selalu akan memengaruhi sisi rollup. Yang belum jelas dari litepaper adalah bagaimana kedua kelompok ini berinteraksi secara operasional: apakah keputusan evaluasi kebijakan dari kumpulan operator yang di-restake harus dikonfirmasi secara terpisah oleh validator rollup yang dipertaruhkan NEWT, atau apakah keduanya berjalan di jalur yang sebagian besar independen yang sama-sama memasok ke attestation yang sama. Yang sedang saya pertimbangkan: menjalankan dua model keamanan terpisah berdampingan adalah pilihan diversifikasi risiko yang nyata, atau artinya saja seorang penyerang hanya perlu menemukan yang lebih lemah dari keduanya, alih-alih membobol satu sistem terpadu. @NewtonProtocol #Newt $NEWT $1000XEC $VELVET
Saya dulu memperlakukan "validator Newton" sebagai satu kelompok dengan satu model keamanan.

Namun itu tidak demikian, begitu Anda menanyakan siapa yang benar-benar mendukung tiap peran.

Rollup Keystore milik Newton, bagian yang menyimpan dan memperbarui izin, diamankan oleh validator yang mempertaruhkan NEWT secara langsung melalui delegated proof-of-stake.

Tapi litepaper menjelaskan peran terpisah, validasi kebijakan (policy validation), yang dilakukan oleh jaringan operator terdesentralisasi yang diamankan oleh Ethereum restaking, bukan sama sekali oleh staking NEWT.

Itulah bagian yang sebelumnya belum saya pisahkan.

"Validator Newton" terdengar seperti satu kelompok orang yang melakukan satu pekerjaan dengan jaminan keamanan yang sama. Padahal, ini sebenarnya dua peran yang berbeda dengan dua pihak pendukung ekonomi yang berbeda.

Validator rollup mempertaruhkan NEWT untuk mengamankan penyimpanan izin dan integritas eksekusi.

Operator kebijakan—yang mengevaluasi transaksi berdasarkan logika kebijakan Rego atau WASM—didukung oleh ETH yang di-restake. Mereka meminjam keamanan validator Ethereum yang sudah ada, bukan membangun aset yang dipertaruhkan baru untuk pekerjaan spesifik tersebut.

Jadi, keamanan sistem ini bukan satu angka saja; ada dua, dan keduanya tidak bergerak bersama.

Sebuah kumpulan validator yang dipertaruhkan NEWT hanya seaman nilai pasar NEWT dan distribusinya. Kumpulan operator yang di-restake ETH mewarisi keamanan dari basis validator yang jauh lebih besar dan sudah mapan.

Kenaikan penurunan harga NEWT akan melemahkan keamanan rollup tanpa harus menyentuh keamanan validasi kebijakan. Sebaliknya, kegagalan yang spesifik untuk restaking tidak selalu akan memengaruhi sisi rollup.

Yang belum jelas dari litepaper adalah bagaimana kedua kelompok ini berinteraksi secara operasional: apakah keputusan evaluasi kebijakan dari kumpulan operator yang di-restake harus dikonfirmasi secara terpisah oleh validator rollup yang dipertaruhkan NEWT, atau apakah keduanya berjalan di jalur yang sebagian besar independen yang sama-sama memasok ke attestation yang sama.

Yang sedang saya pertimbangkan: menjalankan dua model keamanan terpisah berdampingan adalah pilihan diversifikasi risiko yang nyata, atau artinya saja seorang penyerang hanya perlu menemukan yang lebih lemah dari keduanya, alih-alih membobol satu sistem terpadu.

@NewtonProtocol #Newt $NEWT $1000XEC $VELVET
Artikel
Litepaper Menambahkan Satu Kalimat pada Cerita Median. Ini Mengubah Bentuk Masalah Secara Keseluruhan.Saya sudah menyimpulkan bahwa median fase Persiapan Newton dihitung dari operator mana pun yang merespons paling cepat, bukan dari seluruh kumpulan operator yang terdaftar, karena gateway mulai menghitung begitu kuorum terpenuhi. Yang belum pernah saya temukan sampai sekarang adalah apakah keunggulan kecepatan itu kebetulan karena latensi jaringan, atau memang protokol tersebut yang secara aktual memilih untuk itu.   Litepaper Newton menjawabnya secara langsung, dalam sebuah frasa yang mudah dilewatkan: pemilihan operator untuk sebuah tugas dijelaskan sebagai permissionless untuk bergabung, tetapi "performance-weighted" dalam cara operator benar-benar dipilih untuk mengerjakan tugas tertentu.

Litepaper Menambahkan Satu Kalimat pada Cerita Median. Ini Mengubah Bentuk Masalah Secara Keseluruhan.

Saya sudah menyimpulkan bahwa median fase Persiapan Newton dihitung dari operator mana pun yang merespons paling cepat, bukan dari seluruh kumpulan operator yang terdaftar, karena gateway mulai menghitung begitu kuorum terpenuhi.
Yang belum pernah saya temukan sampai sekarang adalah apakah keunggulan kecepatan itu kebetulan karena latensi jaringan, atau memang protokol tersebut yang secara aktual memilih untuk itu.

Litepaper Newton menjawabnya secara langsung, dalam sebuah frasa yang mudah dilewatkan: pemilihan operator untuk sebuah tugas dijelaskan sebagai permissionless untuk bergabung, tetapi "performance-weighted" dalam cara operator benar-benar dipilih untuk mengerjakan tugas tertentu.
Semua orang terpaku pada angka-angka bulat. 10, 100, 1000. Tapi tak ada yang mengadakan parade untuk angka 9. Namun 9 adalah angka yang membuat bilangan bulat mungkin sejak awal, titik pemeriksaan terakhir sebelum hitungan reset dan mulai menanjak lagi. Tanyakan pada penjaga gawang angka berapa yang menghantui mimpi buruk mereka, dan jawabannya tidak pernah 10. Tanyakan pada budaya mana angka apa yang mereka bangun candi dan larangan di sekitarnya, dan setengah dari mereka akan bilang 9. Jumlahkan digit dari 81, 999, atau sebuah bilangan panjang seribu digit. Jika kelipatan 9, ia selalu kembali ke 9, seperti gravitasi untuk aritmetika. Sembilan bulan untuk menumbuhkan seseorang yang sebelumnya tidak ada. Sembilan tahun untuk pertukaran yang mengubah cara dunia menyimpan uang. Saya tidak yakin 9 adalah angka sebelum sesuatu yang lebih besar. Menurut saya, semua yang lebih besar hanyalah 9 yang berpura-pura lupa asalnya. #WhoIsNumber9 Binance Berulang Tahun ke-9 - Dibangun Oleh Anda #BinanceTurns9 $DEXE $DODOX $DODO
Semua orang terpaku pada angka-angka bulat. 10, 100, 1000.

Tapi tak ada yang mengadakan parade untuk angka 9. Namun 9 adalah angka yang membuat bilangan bulat mungkin sejak awal, titik pemeriksaan terakhir sebelum hitungan reset dan mulai menanjak lagi.

Tanyakan pada penjaga gawang angka berapa yang menghantui mimpi buruk mereka, dan jawabannya tidak pernah 10.

Tanyakan pada budaya mana angka apa yang mereka bangun candi dan larangan di sekitarnya, dan setengah dari mereka akan bilang 9.

Jumlahkan digit dari 81, 999, atau sebuah bilangan panjang seribu digit. Jika kelipatan 9, ia selalu kembali ke 9, seperti gravitasi untuk aritmetika. Sembilan bulan untuk menumbuhkan seseorang yang sebelumnya tidak ada.

Sembilan tahun untuk pertukaran yang mengubah cara dunia menyimpan uang. Saya tidak yakin 9 adalah angka sebelum sesuatu yang lebih besar. Menurut saya, semua yang lebih besar hanyalah 9 yang berpura-pura lupa asalnya.

#WhoIsNumber9

Binance Berulang Tahun ke-9 - Dibangun Oleh Anda #BinanceTurns9

$DEXE $DODOX $DODO
Aku terus mengira "diposting ke Ethereum" berarti seluruh riwayat izin berada di sana. Nyatanya tidak. Itu spesifiknya hanya state root. Newton's Keystore adalah rollup yang menangani penyimpanan izin dan pembaruan di luar base layer, tetapi protokol memposting bukti finalitas dan permission state roots ke Ethereum, bukan memposting data izin lengkapnya sendiri. State root adalah komitmen yang dikompresi, satu hash yang mewakili seluruh state saat ini, bukan state itu sendiri. itulah bagian yang sebelumnya belum kupisahkan. Memposting root ke Ethereum berarti siapa pun bisa memverifikasi bahwa suatu state izin tertentu pernah ada pada titik waktu tertentu, tanpa Ethereum pernah menyimpan apa sebenarnya isi dari state tersebut. data yang mendasarinya—siapa yang punya zkPermission, agen mana yang tercakup untuk apa—tetap ada di rollup Keystore. Hanya sidik jarinya (fingerprint) yang di-anchorkan. Inilah yang membuatnya cukup murah untuk dilakukan secara berkelanjutan, bukan terlalu mahal secara prohibitif. Tapi itu juga berarti jaminan yang diberikan Ethereum lebih sempit daripada kedengarannya. Ethereum bisa mengonfirmasi bahwa state root yang diklaim adalah yang memang dikomit. Ethereum tidak bisa memberi tahu apa yang ada di dalam root itu kecuali kamu sudah punya data Keystore yang mendasarinya untuk membandingkan root terhadapnya. Verifikasi membutuhkan dua bagian: anchor dan data yang di-anchorkan, bukan anchor saja. Jadi klaim "di-anchorkan ke Ethereum" tidak sama dengan klaim "bisa dibaca dari Ethereum". Itu adalah komitmen yang bisa kamu audit terhadap data yang harus kamu ambil dari rollup itu sendiri. Dokumentasi Newton mengonfirmasi praktiknya, tetapi tidak menyebutkan seberapa sering root diposting, atau seperti apa jalur verifikasi aktual seorang pengguna jika mereka ingin memeriksa state izin mereka sendiri terhadap root yang di-anchorkan secara langsung. yang sedang kupikirkan: apakah state-root anchoring dirancang agar siapa pun bisa memverifikasi secara independen, atau terutama agar protokol itu sendiri bisa membuktikan integritas, dengan jalur verifikasi individual yang masih belum dibangun. @NewtonProtocol #NEWT $NEWT $DODO $DEXE
Aku terus mengira "diposting ke Ethereum" berarti seluruh riwayat izin berada di sana. Nyatanya tidak. Itu spesifiknya hanya state root.

Newton's Keystore adalah rollup yang menangani penyimpanan izin dan pembaruan di luar base layer, tetapi protokol memposting bukti finalitas dan permission state roots ke Ethereum, bukan memposting data izin lengkapnya sendiri.

State root adalah komitmen yang dikompresi, satu hash yang mewakili seluruh state saat ini, bukan state itu sendiri.

itulah bagian yang sebelumnya belum kupisahkan.

Memposting root ke Ethereum berarti siapa pun bisa memverifikasi bahwa suatu state izin tertentu pernah ada pada titik waktu tertentu, tanpa Ethereum pernah menyimpan apa sebenarnya isi dari state tersebut.

data yang mendasarinya—siapa yang punya zkPermission, agen mana yang tercakup untuk apa—tetap ada di rollup Keystore. Hanya sidik jarinya (fingerprint) yang di-anchorkan. Inilah yang membuatnya cukup murah untuk dilakukan secara berkelanjutan, bukan terlalu mahal secara prohibitif.

Tapi itu juga berarti jaminan yang diberikan Ethereum lebih sempit daripada kedengarannya.

Ethereum bisa mengonfirmasi bahwa state root yang diklaim adalah yang memang dikomit. Ethereum tidak bisa memberi tahu apa yang ada di dalam root itu kecuali kamu sudah punya data Keystore yang mendasarinya untuk membandingkan root terhadapnya.

Verifikasi membutuhkan dua bagian: anchor dan data yang di-anchorkan, bukan anchor saja.

Jadi klaim "di-anchorkan ke Ethereum" tidak sama dengan klaim "bisa dibaca dari Ethereum". Itu adalah komitmen yang bisa kamu audit terhadap data yang harus kamu ambil dari rollup itu sendiri.

Dokumentasi Newton mengonfirmasi praktiknya, tetapi tidak menyebutkan seberapa sering root diposting, atau seperti apa jalur verifikasi aktual seorang pengguna jika mereka ingin memeriksa state izin mereka sendiri terhadap root yang di-anchorkan secara langsung.

yang sedang kupikirkan: apakah state-root anchoring dirancang agar siapa pun bisa memverifikasi secara independen, atau terutama agar protokol itu sendiri bisa membuktikan integritas, dengan jalur verifikasi individual yang masih belum dibangun.

@NewtonProtocol #NEWT $NEWT $DODO $DEXE
Artikel
Aritmetika pada Median Newton. Kata Itu Membawa Lebih dari Sekadar Angka.Fase Persiapan Newton bekerja seperti ini: operator secara independen mengambil data eksternal yang dibutuhkan sebuah kebijakan, melaporkan kembali tanpa tanda tangan, dan begitu respons yang cukup untuk memenuhi kuorum telah tiba, gateway mengambil apa yang ada, membuang nilai tertinggi dan terendah, lalu menghitung sebuah median. Median itu menjadi satu-satunya angka kanonik yang akan dievaluasi setiap operator terhadap kebijakan itu untuk sisa tugas.   "Median" melakukan banyak penenangan dalam kalimat itu. Itu adalah kata yang Anda gunakan ketika ingin mengatakan sebuah nilai tidak bisa digoyahkan oleh satu aktor jahat.

Aritmetika pada Median Newton. Kata Itu Membawa Lebih dari Sekadar Angka.

Fase Persiapan Newton bekerja seperti ini: operator secara independen mengambil data eksternal yang dibutuhkan sebuah kebijakan, melaporkan kembali tanpa tanda tangan, dan begitu respons yang cukup untuk memenuhi kuorum telah tiba, gateway mengambil apa yang ada, membuang nilai tertinggi dan terendah, lalu menghitung sebuah median.
Median itu menjadi satu-satunya angka kanonik yang akan dievaluasi setiap operator terhadap kebijakan itu untuk sisa tugas.

"Median" melakukan banyak penenangan dalam kalimat itu. Itu adalah kata yang Anda gunakan ketika ingin mengatakan sebuah nilai tidak bisa digoyahkan oleh satu aktor jahat.
Artikel
Tanda Tangan Ganda Newton Seharusnya Membuktikan Aplikasi Memverifikasi Pengguna. Saya Mengecek Apakah KriptografinyaSaat sebuah tugas dibuat di Newton, dua pihak harus menyetujui sebelum Gateway melanjutkan: pengguna, dan aplikasi yang bertindak atas nama mereka. Dokumentasi menjelaskannya sebagai sebuah rantai — tanda tangan aplikasi diharapkan memiliki makna spesifik: "kami melihat persetujuan pengguna, kami memverifikasinya, dan hanya setelah itu kami menambahkan persetujuan kami sendiri." Saya ingin melihat apakah konstruksi sebenarnya dari tanda tangan kedua itu benar-benar memastikan urutan tersebut, atau hanya sekadar menegaskan bahwa itu terjadi.   Ini yang dijelaskan. Kedua tanda tangan memverifikasi terhadap pesan dasar yang sama — sebuah ringkasan (digest) yang dibangun dari policy client dan intent hash, dengan referensi data dilipat ke dalamnya. Pengguna menandatanganinya. Aplikasi juga menandatanganinya. Gateway menerima tugas setelah kedua tanda tangan itu sesuai dengan kunci publik masing-masing. Dan tujuan yang dinyatakan dari tanda tangan aplikasi adalah untuk membuktikan bahwa aplikasi tersebut menerima dan memverifikasi persetujuan pengguna sebelum menambahkan persetujuannya sendiri.

Tanda Tangan Ganda Newton Seharusnya Membuktikan Aplikasi Memverifikasi Pengguna. Saya Mengecek Apakah Kriptografinya

Saat sebuah tugas dibuat di Newton, dua pihak harus menyetujui sebelum Gateway melanjutkan: pengguna, dan aplikasi yang bertindak atas nama mereka. Dokumentasi menjelaskannya sebagai sebuah rantai — tanda tangan aplikasi diharapkan memiliki makna spesifik: "kami melihat persetujuan pengguna, kami memverifikasinya, dan hanya setelah itu kami menambahkan persetujuan kami sendiri." Saya ingin melihat apakah konstruksi sebenarnya dari tanda tangan kedua itu benar-benar memastikan urutan tersebut, atau hanya sekadar menegaskan bahwa itu terjadi.

Ini yang dijelaskan. Kedua tanda tangan memverifikasi terhadap pesan dasar yang sama — sebuah ringkasan (digest) yang dibangun dari policy client dan intent hash, dengan referensi data dilipat ke dalamnya. Pengguna menandatanganinya. Aplikasi juga menandatanganinya. Gateway menerima tugas setelah kedua tanda tangan itu sesuai dengan kunci publik masing-masing. Dan tujuan yang dinyatakan dari tanda tangan aplikasi adalah untuk membuktikan bahwa aplikasi tersebut menerima dan memverifikasi persetujuan pengguna sebelum menambahkan persetujuannya sendiri.
jujurnya saya tidak mengira rotasi operator menjadi bagian yang menarik dari desain Newton, tetapi memang demikian. dokumentasi arsitektur privasi Newton menyebut sesuatu yang mudah dilewati: protokol re-share, khususnya proactive secret sharing, yang memungkinkan operator melakukan rotasi tanpa mengubah combined public key. upacara DKG yang mendistribusikan threshold private key hanya berjalan ketika set operator memang berubah, dan itu tidak memengaruhi latensi evaluasi tugas dari hari ke hari. itulah bagian yang sebelumnya belum saya pisahkan. biasanya, jika Anda merotasi peserta dalam sistem threshold, Anda akan mengharapkan seluruh penyiapan kunci ikut berubah bersama mereka, sehingga apa pun yang dienkripsi dengan konfigurasi kunci lama menjadi tidak dapat dibaca begitu set operator bergeser. re-sharing menghindari itu. operator bisa bergantian masuk dan keluar sementara combined public key tetap, yang berarti data yang dienkripsi untuk set operator lama tetap bisa didekripsi oleh yang baru. itulah jaminan yang lebih “tenang” dibanding threshold kuorum atau agregasi BLS, tetapi secara operasional mungkin lebih penting. sistem di mana pergantian operator merusak data terenkripsi sebelumnya adalah sistem yang menghukum desentralisasinya sendiri dari waktu ke waktu: entitas baru tidak bisa bergabung tanpa membuat riwayat menjadi yatim piatu. re-sharing berarti set operator bisa berkembang tanpa pengguna kehilangan akses ke apa yang sudah mereka amankan berdasarkan konfigurasi lama. yang tidak dijelaskan secara gamblang dalam dokumen Newton adalah seberapa sering re-sharing benar-benar perlu dijalankan saat validator set bertambah, atau apa yang terjadi pada data jika upacara re-sharing itu sendiri gagal di tengah jalan. yang sedang saya pertimbangkan: apakah proactive resharing membuat biaya desentralisasi operator menjadi benar-benar gratis dari waktu ke waktu, atau hanya memindahkan titik yang rapuh ke upacara resharing itu sendiri. @NewtonProtocol #NEWT $NEWT $T $CLO
jujurnya saya tidak mengira rotasi operator menjadi bagian yang menarik dari desain Newton, tetapi memang demikian.

dokumentasi arsitektur privasi Newton menyebut sesuatu yang mudah dilewati: protokol re-share, khususnya proactive secret sharing, yang memungkinkan operator melakukan rotasi tanpa mengubah combined public key. upacara DKG yang mendistribusikan threshold private key hanya berjalan ketika set operator memang berubah, dan itu tidak memengaruhi latensi evaluasi tugas dari hari ke hari.

itulah bagian yang sebelumnya belum saya pisahkan.

biasanya, jika Anda merotasi peserta dalam sistem threshold, Anda akan mengharapkan seluruh penyiapan kunci ikut berubah bersama mereka, sehingga apa pun yang dienkripsi dengan konfigurasi kunci lama menjadi tidak dapat dibaca begitu set operator bergeser. re-sharing menghindari itu.

operator bisa bergantian masuk dan keluar sementara combined public key tetap, yang berarti data yang dienkripsi untuk set operator lama tetap bisa didekripsi oleh yang baru.

itulah jaminan yang lebih “tenang” dibanding threshold kuorum atau agregasi BLS, tetapi secara operasional mungkin lebih penting. sistem di mana pergantian operator merusak data terenkripsi sebelumnya adalah sistem yang menghukum desentralisasinya sendiri dari waktu ke waktu: entitas baru tidak bisa bergabung tanpa membuat riwayat menjadi yatim piatu. re-sharing berarti set operator bisa berkembang tanpa pengguna kehilangan akses ke apa yang sudah mereka amankan berdasarkan konfigurasi lama.

yang tidak dijelaskan secara gamblang dalam dokumen Newton adalah seberapa sering re-sharing benar-benar perlu dijalankan saat validator set bertambah, atau apa yang terjadi pada data jika upacara re-sharing itu sendiri gagal di tengah jalan.

yang sedang saya pertimbangkan: apakah proactive resharing membuat biaya desentralisasi operator menjadi benar-benar gratis dari waktu ke waktu, atau hanya memindahkan titik yang rapuh ke upacara resharing itu sendiri.

@NewtonProtocol #NEWT $NEWT $T $CLO
Sudah bermaksud meninjaunya selama berhari-hari: bagaimana validator Newton sebenarnya sepakat atas sebuah attestation, karena "quorum" saja tidak menjelaskan mekanismenya. Newton menggunakan tanda tangan BLS untuk attestation, dan konsensusnya tidak dibangun di sekitar satu digest. Konsensusnya dibangun di sekitar dua digest. Validator menandatangani secara terpisah untuk policy digest dan execution digest untuk intent yang sama. Pemisahan ini berarti kesepakatannya bukan "ya, setujui ini", melainkan dua suara ya yang independen: satu memastikan logika policy terpenuhi dan satu memastikan data pemanggilan aktual yang dieksekusi sesuai dengan yang di-attest. Itulah bagian yang sebelumnya belum saya pisahkan. Skema satu-digest memungkinkan satu tanda tangan menjadi jaminan untuk seluruh intent sekaligus—policy dan execution digabung. Jika salah satu bagiannya dimanipulasi setelah penandatanganan, tidak ada cara untuk mengisolasi bagian mana yang gagal. Dua digest berarti tanda tangan seorang validator bisa dipatahkan terhadap masing-masing bagiannya secara independen. Anda bisa membuktikan bahwa policy-nya benar sementara execution digest-nya rusak, atau sebaliknya—alih-alih satu tanda tangan yang menutupi klaim terpadu yang tidak bisa diurai. Itu jaminan yang jauh lebih kuat daripada sekadar "operator sepakat". Maksudnya operator sepakat pada dua hal yang dapat dipisahkan, digabung melalui BLS sehingga jaringan tetap memverifikasi satu tanda tangan gabungan di rantai. Hal yang tidak dijelaskan secara gamblang dalam dokumentasi Newton adalah apa yang terjadi secara operasional ketika dua digest tersebut tidak cocok untuk satu validator: apakah langsung ditolak, atau ditandai dan diselesaikan melalui logika fallback. Itulah pertanyaan terbuka yang sedang saya pikirkan: apakah pemisahan dua-digest melindungi dari manipulasi parsial, atau hanya memindahkan tempat munculnya ambiguitas. @NewtonProtocol #NEWT $NEWT $B $SKL
Sudah bermaksud meninjaunya selama berhari-hari: bagaimana validator Newton sebenarnya sepakat atas sebuah attestation, karena "quorum" saja tidak menjelaskan mekanismenya.

Newton menggunakan tanda tangan BLS untuk attestation, dan konsensusnya tidak dibangun di sekitar satu digest. Konsensusnya dibangun di sekitar dua digest.

Validator menandatangani secara terpisah untuk policy digest dan execution digest untuk intent yang sama.

Pemisahan ini berarti kesepakatannya bukan "ya, setujui ini", melainkan dua suara ya yang independen: satu memastikan logika policy terpenuhi dan satu memastikan data pemanggilan aktual yang dieksekusi sesuai dengan yang di-attest.

Itulah bagian yang sebelumnya belum saya pisahkan.

Skema satu-digest memungkinkan satu tanda tangan menjadi jaminan untuk seluruh intent sekaligus—policy dan execution digabung. Jika salah satu bagiannya dimanipulasi setelah penandatanganan, tidak ada cara untuk mengisolasi bagian mana yang gagal.

Dua digest berarti tanda tangan seorang validator bisa dipatahkan terhadap masing-masing bagiannya secara independen.

Anda bisa membuktikan bahwa policy-nya benar sementara execution digest-nya rusak, atau sebaliknya—alih-alih satu tanda tangan yang menutupi klaim terpadu yang tidak bisa diurai.

Itu jaminan yang jauh lebih kuat daripada sekadar "operator sepakat". Maksudnya operator sepakat pada dua hal yang dapat dipisahkan, digabung melalui BLS sehingga jaringan tetap memverifikasi satu tanda tangan gabungan di rantai.

Hal yang tidak dijelaskan secara gamblang dalam dokumentasi Newton adalah apa yang terjadi secara operasional ketika dua digest tersebut tidak cocok untuk satu validator: apakah langsung ditolak, atau ditandai dan diselesaikan melalui logika fallback.

Itulah pertanyaan terbuka yang sedang saya pikirkan: apakah pemisahan dua-digest melindungi dari manipulasi parsial, atau hanya memindahkan tempat munculnya ambiguitas.

@NewtonProtocol #NEWT $NEWT $B $SKL
Artikel
Enkripsi Newton Mengikat Dua Hal Secara Kriptografis. Saya Mengecek Apakah Ada Pihak Ke-3 yang Tepat di Atas ItuLapisan privasi Newton membuat klaim keamanan yang presisi: ketika data pribadi dienkripsi dan diunggah, ciphertext secara kriptografis terikat pada kebijakan tertentu dan rantai tertentu. Coba putar ulang sampul terenkripsi yang sama itu di tempat lain—kebijakan yang berbeda, rantai yang berbeda—dan pemeriksaan autentikasi langsung gagal. Dekripsi ditolak. Saya ingin melihat tepatnya apa yang dicakup oleh "terikat pada", dan, yang tak kalah penting, apa yang tidak dicakup.   Ini rumus aslinya. Data autentikasi tambahan yang melekat pada enkripsi dihitung dari tepat dua masukan: klien kebijakan dan ID rantai, di-hash bersama.

Enkripsi Newton Mengikat Dua Hal Secara Kriptografis. Saya Mengecek Apakah Ada Pihak Ke-3 yang Tepat di Atas Itu

Lapisan privasi Newton membuat klaim keamanan yang presisi: ketika data pribadi dienkripsi dan diunggah, ciphertext secara kriptografis terikat pada kebijakan tertentu dan rantai tertentu.
Coba putar ulang sampul terenkripsi yang sama itu di tempat lain—kebijakan yang berbeda, rantai yang berbeda—dan pemeriksaan autentikasi langsung gagal.
Dekripsi ditolak. Saya ingin melihat tepatnya apa yang dicakup oleh "terikat pada", dan, yang tak kalah penting, apa yang tidak dicakup.

Ini rumus aslinya.
Data autentikasi tambahan yang melekat pada enkripsi dihitung dari tepat dua masukan: klien kebijakan dan ID rantai, di-hash bersama.
Artikel
Newton Menyebut Dua Kuncinya "Independen." Saya Menelusuri Rantai yang Diam-Diam Mengikat Keduanya Kembali.Newton memberikan janji keamanan yang spesifik tentang sistem dekripsi ambangnya: kunci penandatanganan harian seorang operator dan bagian mereka dari kunci dekripsi privat jaringan secara kriptografis tidak saling berhubungan. Jika satu dikompromikan, menurut dokumentasinya, yang lain tetap aman. Saya ingin melihat apakah independensi itu terbukti tetap utuh sampai seluruhnya, atau hanya sampai sebagian saja.   Ini adalah arsitektur sebenarnya. Kunci dekripsi ambang Newton dihasilkan sekali, melalui sebuah upacara interaktif di antara para operator, lalu dipecah menjadi beberapa bagian—tidak ada satu pihak pun, bahkan gerbang (gateway) sekalipun, yang pernah memegang semuanya sekaligus. Untuk merekonstruksinya diperlukan kuorum operator yang bekerja sama. Rahasia itu secara matematis adalah sesuatu yang berdiri sendiri, dihasilkan secara independen dari kunci-kunci yang sudah dimiliki operator mana pun. Pada poin spesifik itu, klaim independensinya benar-benar kuat: Anda tidak bisa menurunkan bagian seseorang dari rahasia ambang dari kunci penandatanganannya yang biasa, karena keduanya tidak pernah terhubung secara matematis sejak awal.

Newton Menyebut Dua Kuncinya "Independen." Saya Menelusuri Rantai yang Diam-Diam Mengikat Keduanya Kembali.

Newton memberikan janji keamanan yang spesifik tentang sistem dekripsi ambangnya: kunci penandatanganan harian seorang operator dan bagian mereka dari kunci dekripsi privat jaringan secara kriptografis tidak saling berhubungan. Jika satu dikompromikan, menurut dokumentasinya, yang lain tetap aman. Saya ingin melihat apakah independensi itu terbukti tetap utuh sampai seluruhnya, atau hanya sampai sebagian saja.

Ini adalah arsitektur sebenarnya. Kunci dekripsi ambang Newton dihasilkan sekali, melalui sebuah upacara interaktif di antara para operator, lalu dipecah menjadi beberapa bagian—tidak ada satu pihak pun, bahkan gerbang (gateway) sekalipun, yang pernah memegang semuanya sekaligus. Untuk merekonstruksinya diperlukan kuorum operator yang bekerja sama. Rahasia itu secara matematis adalah sesuatu yang berdiri sendiri, dihasilkan secara independen dari kunci-kunci yang sudah dimiliki operator mana pun. Pada poin spesifik itu, klaim independensinya benar-benar kuat: Anda tidak bisa menurunkan bagian seseorang dari rahasia ambang dari kunci penandatanganannya yang biasa, karena keduanya tidak pernah terhubung secara matematis sejak awal.
bangun tidur saja langsung kepikiran ini, jadi hal pertama besok saya mau menggali di mana sebenarnya state permissions Newton itu tersimpan setelah sudah final, karena "itu ada di sebuah rollup" bukan jawaban yang lengkap. the Keystore adalah sebuah rollup, artinya eksekusi dan pembaruan terjadi di luar base layer demi biaya dan kecepatan. tapi rancangan Newton juga mem-posting finality proofs dan permission state roots ke Ethereum. itu klaim yang berbeda daripada "rollup-nya aman". ini berarti keadaan yang sebenarnya—siapa yang punya izin untuk melakukan apa—di-anker ke L1, bukan sekadar diproses di sana sesekali. itulah bagian yang sebelumnya belum saya pisahkan. sebuah rollup yang hanya mengeksekusi di luar-chain berarti Anda mempercayai sequencer dan validator set-nya sendiri untuk catatan kebenaran. sebuah rollup yang mem-post state roots ke Ethereum berarti siapa pun bisa memeriksa root yang dikomit terhadap L1 dan memverifikasi seperti apa permission state pada saat itu, tanpa perlu mempercayai operator internal rollup untuk melaporkannya dengan jujur. rollup menangani throughput. Ethereum menangani jangkar yang tidak bisa dikendalikan. jadi pertanyaan keamanan yang sesungguhnya bukan "apakah Keystore cepat", melainkan "seberapa sering state di-anker, dan apa yang bisa diverifikasi hanya dari root saja dibandingkan apa yang masih memerlukan kepercayaan pada state internal rollup di antara waktu anchor." Dokumen Newton mengonfirmasi bahwa state roots diposting ke Ethereum untuk finality, tapi tidak merinci seberapa sering anchoring dilakukan atau seperti apa eksposur pengguna yang sebenarnya di jendela antara satu root yang diposting dan berikutnya, jika terjadi masalah pada rollup di tengah jendela itu. itulah yang ingin saya cari besok: apakah celah di antara anchor itu cukup kecil sehingga pada dasarnya hanya bersifat teoritis, atau apakah ini benar-benar jendela nyata ketika Keystore masih meminta saya untuk mempercayainya sebelum Ethereum sempat memeriksa pekerjaannya. @NewtonProtocol #Newt $NEWT $POWER $LAB
bangun tidur saja langsung kepikiran ini, jadi hal pertama besok saya mau menggali di mana sebenarnya state permissions Newton itu tersimpan setelah sudah final, karena "itu ada di sebuah rollup" bukan jawaban yang lengkap.

the Keystore adalah sebuah rollup, artinya eksekusi dan pembaruan terjadi di luar base layer demi biaya dan kecepatan. tapi rancangan Newton juga mem-posting finality proofs dan permission state roots ke Ethereum.

itu klaim yang berbeda daripada "rollup-nya aman". ini berarti keadaan yang sebenarnya—siapa yang punya izin untuk melakukan apa—di-anker ke L1, bukan sekadar diproses di sana sesekali.

itulah bagian yang sebelumnya belum saya pisahkan.

sebuah rollup yang hanya mengeksekusi di luar-chain berarti Anda mempercayai sequencer dan validator set-nya sendiri untuk catatan kebenaran.

sebuah rollup yang mem-post state roots ke Ethereum berarti siapa pun bisa memeriksa root yang dikomit terhadap L1 dan memverifikasi seperti apa permission state pada saat itu, tanpa perlu mempercayai operator internal rollup untuk melaporkannya dengan jujur.

rollup menangani throughput. Ethereum menangani jangkar yang tidak bisa dikendalikan.

jadi pertanyaan keamanan yang sesungguhnya bukan "apakah Keystore cepat", melainkan "seberapa sering state di-anker, dan apa yang bisa diverifikasi hanya dari root saja dibandingkan apa yang masih memerlukan kepercayaan pada state internal rollup di antara waktu anchor."

Dokumen Newton mengonfirmasi bahwa state roots diposting ke Ethereum untuk finality, tapi tidak merinci seberapa sering anchoring dilakukan atau seperti apa eksposur pengguna yang sebenarnya di jendela antara satu root yang diposting dan berikutnya, jika terjadi masalah pada rollup di tengah jendela itu.

itulah yang ingin saya cari besok: apakah celah di antara anchor itu cukup kecil sehingga pada dasarnya hanya bersifat teoritis, atau apakah ini benar-benar jendela nyata ketika Keystore masih meminta saya untuk mempercayainya sebelum Ethereum sempat memeriksa pekerjaannya.

@NewtonProtocol #Newt $NEWT $POWER $LAB
Masuk untuk menjelajahi konten lainnya
Bergabunglah dengan pengguna kripto global di Binance Square
⚡️ Dapatkan informasi terbaru dan berguna tentang kripto.
💬 Dipercayai oleh bursa kripto terbesar di dunia.
👍 Temukan wawasan nyata dari kreator terverifikasi.
Email/Nomor Ponsel
Sitemap
Preferensi Cookie
S&K Platform