Saya mulai mempertanyakan narasi jumlah gerbang DUSK ketika XOR 8 bit yang dimodelkan turun dari 31 gerbang menjadi satu pencarian PlonKup. Kompresinya terlihat sangat menakjubkan, 96,8%. Namun itu mencerminkan aritmetika rangkaian, bukan kecepatan proses pembuktian yang sebenarnya.
Pencarian tetap menghadirkan penanganan tabel, pengurutan komitmen, dan tekanan memori. Jadi 31× lebih sedikit gerbang tidak berarti 31× lebih cepat pembuktian. Biayanya bisa saja bergeser ke RAM.
Hal ini penting karena panduan operator DUSK mengalokasikan sekitar 1 GB per pekerja proof dan 8 GB untuk server minimum. Angka-angka itu adalah estimasi ukuran, bukan memori puncak yang diukur. Metrik yang hilang adalah jumlah proof per GB pada beban P50 dan P99, terutama dengan pekerja yang berjalan bersamaan.
Lalu soal aksesibilitas. Apa yang terjadi pada ponsel kelas menengah setelah panas, aplikasi latar belakang, dan pembuktian berulang? Jika P50 dapat diterima tetapi P99 tersendat, itu menjadi gesekan bagi pengguna, bukan sekadar kemenangan kriptografi.
Saya juga mengawasi proof yang cacat. Berapa banyak CPU yang dapat dikonsumsi oleh input yang tidak valid sebelum ditolak, dan seberapa banyak penyaringan awal dapat menghemat? Sebagian overhead itu normal. Namun amplifikasi tanpa batas tidak.
DUSK bisa berhasil jika kompresi lookup meningkatkan throughput nyata tanpa memusatkan proses pembuktian pada perangkat keras ber-RAM tinggi. Sampai DUSK memublikasikan metrik waktu proof puncak, penggunaan energi RAM puncak, dan benchmark penolakan proof yang tidak valid, semuanya masih belum lengkap.
#dusk $DUSK @Dusk
Pencarian tetap menghadirkan penanganan tabel, pengurutan komitmen, dan tekanan memori. Jadi 31× lebih sedikit gerbang tidak berarti 31× lebih cepat pembuktian. Biayanya bisa saja bergeser ke RAM.
Hal ini penting karena panduan operator DUSK mengalokasikan sekitar 1 GB per pekerja proof dan 8 GB untuk server minimum. Angka-angka itu adalah estimasi ukuran, bukan memori puncak yang diukur. Metrik yang hilang adalah jumlah proof per GB pada beban P50 dan P99, terutama dengan pekerja yang berjalan bersamaan.
Lalu soal aksesibilitas. Apa yang terjadi pada ponsel kelas menengah setelah panas, aplikasi latar belakang, dan pembuktian berulang? Jika P50 dapat diterima tetapi P99 tersendat, itu menjadi gesekan bagi pengguna, bukan sekadar kemenangan kriptografi.
Saya juga mengawasi proof yang cacat. Berapa banyak CPU yang dapat dikonsumsi oleh input yang tidak valid sebelum ditolak, dan seberapa banyak penyaringan awal dapat menghemat? Sebagian overhead itu normal. Namun amplifikasi tanpa batas tidak.
DUSK bisa berhasil jika kompresi lookup meningkatkan throughput nyata tanpa memusatkan proses pembuktian pada perangkat keras ber-RAM tinggi. Sampai DUSK memublikasikan metrik waktu proof puncak, penggunaan energi RAM puncak, dan benchmark penolakan proof yang tidak valid, semuanya masih belum lengkap.
#dusk $DUSK @Dusk