Lompat ke konten
Financial Context Wiki

Bukti Riwayat: Batasan Pengurutan, Kutu, Slot, dan Konsensus yang Tercatat

Proof of History adalah jam rantai hash berurutan Solana: mekanisme ini membuat urutan tercatat dan jumlah komputasi dapat diverifikasi, tetapi tidak dengan sendirinya membuktikan waktu nyata, keadilan urutan kedatangan, pilihan fork, atau finalitas.

Diperbarui

Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Proof of History, atau PoH, adalah jam kriptografi dan struktur data pemesanan buku besar Solana. Produsen berulang kali menerapkan fungsi hash sehingga setiap keluaran bergantung pada keluaran sebelumnya, mencatat jumlah dan status secara berkala, dan menggabungkan data turunan transaksi ke dalam rantai. Pemverifikasi dapat menghitung ulang transisi tersebut dan mengonfirmasi urutan yang dicatat oleh rantai tertentu tersebut.

PoH bukanlah algoritme konsensus yang berdiri sendiri. Ia tidak memilih cabang kanonik, menyediakan perjanjian pembobotan saham, menyelesaikan blok, atau membuktikan bahwa suatu transaksi mencapai jaringan pada waktu sipil tertentu. Solana menggabungkan jam dengan pemimpin terjadwal, eksekusi transaksi, suara validator, pilihan fork, dan penguncian gaya Tower BFT. Dua fork masing-masing dapat berisi urutan PoH yang valid secara internal; aturan konsensus menentukan riwayat mana yang diikuti jaringan.

Cakupan jaminan ini terbatas. Jika sebuah entri mengikat data d setelah status h2, status berikutnya h3 = H(h2 || d) tidak dapat dihitung tanpa komitmen itu. Hal ini membuktikan bahwa produsen mengetahui d sebelum h3 dan menetapkan posisi tercatatnya terhadap keluaran berikutnya. Ini tidak membuktikan waktu penerimaan tiap validator, keadilan urutan kedatangan, kebenaran data eksternal, atau bahwa entri tersebut menjadi kanonis.

Pembuatan dilakukan secara berurutan karena masukan berikutnya tidak diketahui hingga hash sebelumnya ada. Status batas yang dipublikasikan memungkinkan pemverifikasi memutar ulang segmen berbatas terpisah secara paralel, namun pekerjaan hash agregat tetap ada. Oleh karena itu, PoH sering dibandingkan dengan fungsi penundaan yang dapat diverifikasi, sedangkan penjelasan Tower BFT milik Tower BFT menyebutnya sebagai penggunaan istilah tersebut secara longgar; VDF formal biasanya memiliki antarmuka evaluasi dan verifikasi yang verifikasinya relatif efisien dibandingkan evaluasi berurutan.

Cara menganalisis Bukti Riwayat

  1. Memperbaiki konteks jaringan dan perangkat lunak. Jaringan rekaman, hash genesis, slot, epoch, Agave atau versi klien lainnya, dan waktu pengamatan. Baca nilai aktif seperti hashes_per_tick, ticks_per_slot dan ns_per_slot; jangan mengimpor konstanta dari artikel lama atau cluster lain.
  2. Rekonstruksi rantai hash. Mulai dari status pendahulunya yang tepercaya dan verifikasi num_hashes setiap entri, yang menghasilkan hash dan daftar transaksi. Dalam implementasi entri Agave, pengidentifikasi entri bergantung pada entri sebelumnya dan, ketika ada transaksi, hash berasal dari tanda tangannya.
  3. Validasi tick dan penempatan slot. Periksa entri tick, jumlah hash yang diharapkan, tinggi tick, dan tinggi tick maksimum terhadap aturan bank dan perekam. Perekam memetakan ketinggian tick ke dalam slot menggunakan ticks_per_slot yang dikonfigurasi; slot adalah interval protokol, bukan bukti independen dari jam eksternal.
  4. Membedakan penyertaan dari kedatangan. Komitmen membuktikan bahwa masukan diketahui paling lambat setelah dimasukkan ke dalam urutan tersebut. Untuk mengklaim batas bawah, identifikasi referensi balik yang ditandatangani ke status PoH sebelumnya. Tidak ada batasan yang membuktikan urutan global yang pertama kali dilihat, keadilan mempool, atau stempel waktu UTC yang tepercaya.
  5. Pembuatan terpisah dari verifikasi. Mengukur produksi berurutan pada satu rantai ketergantungan, lalu mengukur pemutaran ulang menggunakan batas segmen yang diautentikasi dan inti yang tersedia. Laporkan hash total, latensi jalur kritis, pekerjaan verifikasi agregat, dan asumsi data batas, bukan sekadar mengatakan bahwa verifikasi itu “cepat.”
  6. Lacak jalur konsensus. Identifikasi pemimpin terjadwal, negara bagian bank, pemungutan suara, lockout, aturan pilihan fork, status rooting atau final, dan tingkat komitmen. Rantai PoH yang valid masih dapat dimiliki oleh fork yang kalah, dan penghitung yang terlihat lebih panjang saja bukanlah sertifikat konsensus.
  7. Tekankan kasus-kasus permusuhan dan operasional. Pengabaian pemimpin pengujian, penghilangan dan penyusunan ulang transaksi, slot, partisi yang dilewati, perangkat keras yang lebih cepat atau salah dikalibrasi, jumlah tick yang tidak valid, tertunda pemutaran ulang, tidak tersedianya buku besar, divergensi klien, dan kontrol operator atau infrastruktur yang berkorelasi.

Keluaran tinjauan harus membedakan empat klaim: validitas urutan, waktu protokol yang dikonfigurasi, status konsensus, dan waktu eksternal. Nyatakan data hash dan buku besar awal mana yang dipercaya, hash mana yang dihitung ulang, bukti pemungutan suara atau komitmen apa yang diperiksa, dan observasi mana yang berasal dari jam lokal atau layanan pihak ketiga.

Contoh yang berhasil

1. Penyisipan data memperbaiki posisi yang tercatat

Pertimbangkan h1 = H(h0), lalu h2 = H(h1). Produsen memasukkan komitmen turunan transaksi d dan menghitung h3 = H(h2 || d), diikuti oleh h4 = H(h3). Siapa pun yang memutar ulang operasi yang sama dapat memverifikasi bahwa rantai yang direkam melakukan d antara h2 dan h3, dan bahwa h4 bergantung pada hasilnya.

Pernyataan batas atasnya sempit: produser mengetahui d sebelum menghitung h3. Jika transaksi yang ditandatangani itu sendiri merujuk pada h1, verifikator juga dapat menunjukkan bahwa transaksi tersebut terbentuk setelah mengetahui keadaan sebelumnya, dengan tunduk pada pemeriksaan tanda tangan dan asal. Tanpa referensi balik seperti itu, PoH sendiri tidak menyediakan batas bawah. Tidak ada kasus yang membuktikan kapan node lain pertama kali menerima transaksi.

2. Pemutaran ulang segmen mengurangi latensi, bukan pekerjaan agregat

Misalkan interval yang tercatat berisi 1.000.000 hash dan pos pemeriksaan yang diautentikasi membaginya menjadi 10 segmen yang terdiri dari 100.000 hash. Dengan inti yang memadai, sepuluh segmen dapat diputar ulang secara bersamaan, sehingga latensi verifikasi jam dinding mungkin mendekati durasi satu segmen ditambah overhead.

Pemverifikasi secara kolektif masih mengeksekusi 1.000.000 hash; pos-pos pemeriksaan mengekspos negara-negara awal yang independen tetapi tidak mengubah rantai menjadi bukti yang ringkas. Kinerja bergantung pada perangkat keras, penjadwalan, pergerakan memori, dan keyakinan terhadap batasan. Inilah sebabnya mengapa pemutaran ulang PoH paralel tidak secara otomatis digambarkan sebagai algoritme verifikasi yang efisien untuk setiap konstruksi formal VDF.

3. Aritmatika centang dan slot bergantung pada konfigurasi

Asumsikan konfigurasi ilustratif dengan hashes_per_tick = 100,000 dan ticks_per_slot = 8. Slot yang di-hash sepenuhnya kemudian berisi hash 100,000 * 8 = 800,000, dengan batas centang setelah setiap interval yang dikonfigurasi. Mengubah salah satu parameter akan mengubah pemetaan; contoh ini bukan konstanta mainnet saat ini.

Agave juga mendukung kasus protokol di mana perilaku jumlah hash diwakili oleh konfigurasi, bukan perkalian sederhana ini. Peninjau harus mendapatkan kolom aktual bank dan memvalidasi entri berdasarkan aturan klien. Mengonversi slot atau hitungan menjadi detik juga bergantung pada kalibrasi durasi target dan eksekusi yang diamati, bukan hanya verifikasi kriptografi.

4. Urutan tercatat bukan urutan kedatangan atau finalitas

Misalkan transaksi A mencapai pemimpin sebelum transaksi B, namun pemimpin mencatat B mendekati hitungan 300.000 dan A mendekati hitungan 450.000. PoH yang valid membuktikan bahwa B mendahului A dalam barisan yang dihasilkan. Itu tidak membuktikan bahwa B datang lebih dulu, bahwa perintahnya adil, atau bahwa pemimpin lain menjalankan perintah yang sama.

Sekarang misalkan sebuah partisi menghasilkan fork X dan fork Y, masing-masing dengan urutan yang valid. Validasi PoH dapat menolak entri yang salah format pada salah satu fork, namun tidak memilih X atau Y. Jadwal pemimpin, suara tertimbang taruhan, lockout, pilihan fork, dan tingkat komitmen yang diminta menentukan hasil konsensus; aplikasi tidak boleh menggantikan jumlah PoH untuk konfirmasi atau bukti finalitas.

Risiko dan kegagalan peninjauan

Kesalahan kriptografi dan pengaturan waktu

  • Menyebut PoH sebagai jam dinding tepercaya atau mengklaim jumlah hash secara independen membuktikan stempel waktu UTC.
  • Mengatakan penyertaan transaksi membuktikan waktu penerimaan di seluruh jaringan, urutan pertama kali dilihat, atau kebenaran data eksternal.
  • Dengan asumsi pembuatan berurutan mencegah produsen menahan, menghilangkan, atau memilih kapan harus memasukkan data yang diketahui.
  • Menganggap resistensi tabrakan saja sebagai batasan lengkap pada kecepatan perangkat keras, penyimpangan kalibrasi, atau varian implementasi.
  • Mendeskripsikan pemutaran ulang segmen paralel sebagai nol berfungsi atau sebagai bukti ringkas tanpa menghitung hash agregat.
  • Menyebut PoH sebagai VDF formal tanpa menyebutkan konstruksinya, antarmuka bukti, dan asumsi verifikasi dibandingkan.
  • Mempercayai batasan pos pemeriksaan, hash pendahulu, atau segmen buku besar yang diunduh tanpa mengautentikasi asal usulnya.

Konsensus dan protokol error

  • Memanggil konsensus PoH, bukti kepemilikan, Tower BFT, pemilihan pemimpin, pilihan fork, dan finalitas dengan mekanisme yang sama.
  • Mengasumsikan urutan valid dengan penghitungan tertinggi harus bersifat kanonik tanpa memeriksa suara dan status pilihan fork.
  • Memperlakukan entri yang diputar ulang secara lokal sebagai dikonfirmasi, di-root, atau diselesaikan tanpa memeriksa semantik komitmen yang diminta.
  • Menggunakan nilai historis hashes_per_tick, ticks_per_slot, atau durasi slot sebagai konstanta saat ini yang berlaku universal.
  • Mengabaikan slot yang dilewati, rotasi pemimpin, partisi, dalih, dan perbedaan versi klien saat merekonstruksi pesanan.
  • Membandingkan jumlah dari fork atau status awal yang tidak terkait seolah-olah mereka berasal dari satu urutan yang diautentikasi.
  • Dengan asumsi blockhash terbaru suatu transaksi hanyalah stempel waktu jam dinding dan bukan konteks validitas protokol.

Kesalahan operasi, kinerja, dan kontrol

  • Membandingkan pembuatan hash saja sambil mengabaikan eksekusi, verifikasi tanda tangan, pemutaran ulang, bandwidth dan penyimpanan.
  • Menyamakan paralelisme segmen teoretis dengan kejar-kejaran validator yang diamati pada CPU, I/O, dan pertikaian memori.
  • Mengabaikan kegagalan validasi tick, pencatatan terhenti, perbankan tertunda, kesenjangan buku besar, kepercayaan snapshot, dan status rusak.
  • Menghitung identitas validator sebagai independen saat klien, hosting, jaringan, infrastruktur atau kendali utama dibagikan.
  • Dengan asumsi perangkat keras yang lebih cepat menghilangkan latensi jaringan, kehilangan paket, sensor, penolakan layanan, atau risiko konsentrasi pasak.
  • Menyajikan durasi slot target, perkiraan throughput, atau tolok ukur lama sebagai jaminan tingkat layanan.

Kesalahpahaman umum

  • PoH adalah algoritme konsensus lengkap Solana. PoH menyediakan urutan rekaman yang dapat diverifikasi; pemungutan suara validator, lockout, pilihan fork, dan aturan konsensus lainnya menentukan riwayat yang diikuti oleh jaringan.
  • PoH membuktikan waktu sebenarnya di dunia nyata untuk setiap transaksi. Ini membuktikan ketergantungan dan penghitungan dalam urutan yang diautentikasi; memetakan urutan tersebut ke waktu sipil memerlukan konfigurasi dan pengamatan eksternal.
  • PoH menjamin pengurutan transaksi yang adil. Pemimpin dapat memilih, menunda, menyusun ulang, atau menghilangkan masukan dalam batasan protokol dan sumber daya; PoH hanya membuat urutan hasil yang tercatat dapat diaudit.
  • PoH adalah penambangan bukti kerja dengan nama lain. Keduanya menggunakan hashing, tetapi peran inti PoH adalah jam berurutan, bukan perlombaan paralel terbuka yang pekerjaan pemenangnya memilih rantai.
  • Setiap urutan PoH yang valid adalah final. Fork yang bersaing masing-masing mungkin valid secara internal; konfirmasi dan finalitas memerlukan bukti konsensus jaringan.

Topik terkait

Sumber

Navigasi

Cari di wiki...