Solana menekan slot pembuatan blok dari 300 milidetik menjadi 250 milidetik; jam di rantai jadi sekitar 17% lebih cepat. Namun, kapasitas komputasi dan data yang boleh dimuat di tiap slot ikut turun secara proporsional, jadi throughput total tidak bertambah.
Istilah teknisnya kurang enak dijelaskan, jadi begini versi lain. Stasiun kereta memperkecil interval keberangkatan dari 30 detik menjadi 25 detik. Setiap kereta tetap membawa jumlah orang yang sama—kapasitas per jam tidak berubah—hanya antrean di peron yang jadi tidak terlalu padat.
Biaya dampaknya jatuh di tempat lain. Epoch dipangkas jadi sekitar 30 jam; jendela untuk tanda tangan saat offline dan persetujuan tertunda ikut memendek. Proses untuk market maker dan layanan pengelolaan (custody) harus disesuaikan ulang. Kali ini yang diubah adalah ritme (tempo), bukan kapasitas.
Orang yang mengurus infrastruktur punya kebiasaan: urusan parameter dulu baru ngomong soal arsitektur, karena begitu parameter diubah, hari itu juga bisa langsung diumumkan. Bagian yang sulit justru menaikkan batas atas beban yang bisa ditampung oleh satu blok—itu menyentuh state, biaya penyimpanan, dan ambang untuk validator; ubahnya lambat dan juga kurang “cakep”.
Saya kurang percaya klaim soal percepatan 17% itu sebagai inti ceritanya. Angkanya memang benar, ditaruh di tabel juga terlihat rapi—tapi itu menjawab apakah rantai bereaksi lebih cepat, bukan apakah rantai bisa memuat lebih banyak. Total muatan rantai tidak berubah, yang berubah hanya pengalaman. Perubahan seperti ini menguntungkan pihak yang butuh frekuensi tinggi, tapi tidak membantu mereka yang mengutamakan konfirmasi setara (equal/peer confirmation).
Yang perlu diawasi ada dua angka lain: apakah setelah upgrade tingkat transaksi gagal turun, dan apakah prioritas fee (prioritiy fee/“prior fee”) ikut turun secara jelas. Kalau turun, berarti memang mengencangkan ritme berhasil mengobati kemacetan. Kalau tidak turun, artinya tabelnya dipercepat, kerjaannya tetap segitu banyak.
#SOL naik sekitar 10% #Solana
Istilah teknisnya kurang enak dijelaskan, jadi begini versi lain. Stasiun kereta memperkecil interval keberangkatan dari 30 detik menjadi 25 detik. Setiap kereta tetap membawa jumlah orang yang sama—kapasitas per jam tidak berubah—hanya antrean di peron yang jadi tidak terlalu padat.
Biaya dampaknya jatuh di tempat lain. Epoch dipangkas jadi sekitar 30 jam; jendela untuk tanda tangan saat offline dan persetujuan tertunda ikut memendek. Proses untuk market maker dan layanan pengelolaan (custody) harus disesuaikan ulang. Kali ini yang diubah adalah ritme (tempo), bukan kapasitas.
Orang yang mengurus infrastruktur punya kebiasaan: urusan parameter dulu baru ngomong soal arsitektur, karena begitu parameter diubah, hari itu juga bisa langsung diumumkan. Bagian yang sulit justru menaikkan batas atas beban yang bisa ditampung oleh satu blok—itu menyentuh state, biaya penyimpanan, dan ambang untuk validator; ubahnya lambat dan juga kurang “cakep”.
Saya kurang percaya klaim soal percepatan 17% itu sebagai inti ceritanya. Angkanya memang benar, ditaruh di tabel juga terlihat rapi—tapi itu menjawab apakah rantai bereaksi lebih cepat, bukan apakah rantai bisa memuat lebih banyak. Total muatan rantai tidak berubah, yang berubah hanya pengalaman. Perubahan seperti ini menguntungkan pihak yang butuh frekuensi tinggi, tapi tidak membantu mereka yang mengutamakan konfirmasi setara (equal/peer confirmation).
Yang perlu diawasi ada dua angka lain: apakah setelah upgrade tingkat transaksi gagal turun, dan apakah prioritas fee (prioritiy fee/“prior fee”) ikut turun secara jelas. Kalau turun, berarti memang mengencangkan ritme berhasil mengobati kemacetan. Kalau tidak turun, artinya tabelnya dipercepat, kerjaannya tetap segitu banyak.
#SOL naik sekitar 10% #Solana
