Salah satu konsekuensi positif dari semua pemikiran mendetail terbaru mengenai format transaksi—tidak hanya 8141, tetapi juga diskusi “masa depan state” seperti UTXO, PBT, keyed nonces, dan recursive STARK mempool—adalah kita kini memiliki pemahaman yang jauh lebih eksplisit tentang bagaimana transaksi memiliki “tindakan” dan “ketergantungan”, sehingga kita dapat merekayasa optimasi keduanya secara terpisah. Sebuah tindakan adalah efek yang dihasilkan oleh sebuah transaksi. Sebuah ketergantungan adalah fakta mengenai transaksi dan/atau state yang harus benar agar transaksi tersebut valid. Contoh: tanda tangan adalah ketergantungan, bukti Merkle dari UTXO adalah ketergantungan, ZK-SNARK (atau STARK) adalah ketergantungan, panggilan yang mengirim ETH adalah tindakan. Ketergantungan dapat diproses secara paralel. Ketergantungan yang melibatkan state dapat dianalisis oleh mempool, terutama jika state yang diakses dinyatakan secara statis. Ketergantungan yang murni (tidak diperbolehkan memanggil state) dapat diproses sekali saja di lapisan mempool dan tidak perlu diproses lagi—bahkan berpotensi diganti dengan STARK yang memverifikasinya, memungkinkan tidak hanya eksekusi tetapi juga data untuk dihilangkan. Pada prinsipnya, ketergantungan dan tindakan semuanya dapat dinyatakan sebagai panggilan (jika diperlukan, panggilan ke precompile). Ini akan membuat format transaksi itu sendiri sangat minimalis (daftar panggilan, flag untuk jenis setiap panggilan—misalnya, ketergantungan adalah panggilan statis atau murni, serta origin, nonce, dll) dan memungkinkan kompatibilitas lintas-platform maksimal meskipun rantai EVM berbeda fitur. Pada era Ethereum 2015, memikirkan perbedaan ini secara eksplisit tidak terlalu penting: eksekusi adalah eksekusi, jumlah transaksi cukup sedikit sehingga kita bisa memprosesnya secara serial, dan akun ECDSA satu-kunci sudah cukup baik untuk semua orang. Namun, strategi penskalaan Ethereum saat ini memerlukan perpindahan melewati paradigma tersebut. Ethereum disukai banyak pengembang karena model eksekusi dan state-nya sangat dinamis dan fleksibel. Tetapi dinamis dan fleksibel tidak ramah terhadap penskalaan. Untungnya, >90% aktivitas Ethereum berdasarkan volume tidak memerlukan sesuatu yang dinamis dan fleksibel. Jadi, kita memerlukan kontrak, akun, dan transaksi untuk secara eksplisit menentukan apa yang dinamis dan fleksibel serta apa yang lebih dapat dianalisis secara statis namun lebih terbatas; hal-hal yang lebih dapat dianalisis secara statis mendapatkan biaya gas terendah dan thus berskala paling besar. Secara efektif, kita belajar dari yang terbaik dari model Ethereum era 2015 dan model yang lebih mirip Bitcoin (pengingat: Bitcoin telah memiliki apa yang saya sebut account abstraction sejak awal), dan menyediakan campuran keduanya (sebenarnya, spektrum penuh di antara keduanya), dengan biaya gas yang sesuai tingkat penskalaan yang terlibat. Jenis state baru, recursive STARK mempool, keyed nonces, dll semuanya menuju arah ini. Semua ini terkait dengan jenis transaksi, karena jenis transaksi generik adalah lapisan antarmuka alami di atasnya semua ini dapat diimplementasikan, dan pemikiran saat ini mengenai jenis transaksi EIP-8141 sedang bergerak tepat ke arah ini—ramah terhadap generalisasi semacam ini di masa depan. Jadi dalam pengertian itu, 8141 yang dilakukan dengan baik bukan hanya puncak dari 10 tahun kerja account abstraction, tetapi juga persiapan untuk beberapa tahun ke depan dalam hyper-scaling yang bertanggung jawab dan ramah desentralisasi.
vitalik.ethBagikan
Sumber:Tampilkan versi asli
Penafian: Informasi pada halaman ini mungkin telah diperoleh dari pihak ketiga dan tidak mencerminkan pandangan atau opini KuCoin. Konten ini disediakan hanya untuk tujuan informasi umum, tanpa representasi atau jaminan apa pun, dan tidak dapat ditafsirkan sebagai saran keuangan atau investasi. KuCoin tidak bertanggung jawab terhadap segala kesalahan atau kelalaian, atau hasil apa pun yang keluar dari penggunaan informasi ini.
Berinvestasi di aset digital dapat berisiko. Harap mengevaluasi risiko produk dan toleransi risiko Anda secara cermat berdasarkan situasi keuangan Anda sendiri. Untuk informasi lebih lanjut, silakan lihat Ketentuan Penggunaan dan Pengungkapan Risiko.
