@Dusk_Foundation Saya mendapati diri saya menatap pohon catatan Phoenix milik DUSK Network karena kedalaman 34 terdengar seperti pilihan implementasi yang kecil, tetapi perilaku penskalaannya bukanlah hal kecil.
Angka yang paling jelas adalah 17.179.869.184 kemungkinan daun. Saya pikir angka itu justru menjadi gangguan. Phoenix mendefinisikan pohon Merkle biner pada kedalaman 34 sehingga kapasitas tumbuh secara eksponensial sementara jalur inklusi hanya tumbuh secara linear. Setiap input yang sudah dibelanjakan tetap perlu memiliki jalur Merkle yang valid menuju anchor-nya.
Bandingkan kedalaman 32 yang memberi sekitar 4,29B daun, kedalaman 34 memberi 17,18B, dan kedalaman 36 memberi 68,72B. Dua level tambahan mengalikan kapasitas menjadi 4×. Dari 34 ke 35 kapasitas kembali berlipat dua, sementara kedalaman jalur bertambah dari 34 menjadi 35 langkah—hanya sekitar 2,9%.
Itu terlihat efisien untuk DUSK. Tetapi kapasitas teoretis tidak sama dengan pengelolaan riwayat yang benar-benar terjadi.
Uji sesungguhnya adalah laju pembuatan catatan dibandingkan biaya pembuktian dan disiplin penyimpanan.
Seberapa cepat pohon benar-benar terisi? Apa yang terjadi pada biaya proving, penanganan witness, penyimpanan arsip, dan akses state seiring riwayat terus bertambah?
Sebagian overhead itu normal. Privasi membutuhkan struktur.
Yang masih saya ragukan adalah apakah DUSK Network memilih kedalaman yang tetap nyaman untuk penggunaan nyata, bukan hanya secara matematis sangat besar.
#dusk $DUSK #dusk $DUSK @Dusk
Angka yang paling jelas adalah 17.179.869.184 kemungkinan daun. Saya pikir angka itu justru menjadi gangguan. Phoenix mendefinisikan pohon Merkle biner pada kedalaman 34 sehingga kapasitas tumbuh secara eksponensial sementara jalur inklusi hanya tumbuh secara linear. Setiap input yang sudah dibelanjakan tetap perlu memiliki jalur Merkle yang valid menuju anchor-nya.
Bandingkan kedalaman 32 yang memberi sekitar 4,29B daun, kedalaman 34 memberi 17,18B, dan kedalaman 36 memberi 68,72B. Dua level tambahan mengalikan kapasitas menjadi 4×. Dari 34 ke 35 kapasitas kembali berlipat dua, sementara kedalaman jalur bertambah dari 34 menjadi 35 langkah—hanya sekitar 2,9%.
Itu terlihat efisien untuk DUSK. Tetapi kapasitas teoretis tidak sama dengan pengelolaan riwayat yang benar-benar terjadi.
Uji sesungguhnya adalah laju pembuatan catatan dibandingkan biaya pembuktian dan disiplin penyimpanan.
Seberapa cepat pohon benar-benar terisi? Apa yang terjadi pada biaya proving, penanganan witness, penyimpanan arsip, dan akses state seiring riwayat terus bertambah?
Sebagian overhead itu normal. Privasi membutuhkan struktur.
Yang masih saya ragukan adalah apakah DUSK Network memilih kedalaman yang tetap nyaman untuk penggunaan nyata, bukan hanya secara matematis sangat besar.
#dusk $DUSK #dusk $DUSK @Dusk