Terjemahan dan pengoreksian: "Komunitas Tionghoa StarkNet"
Ringkasan
Fungsi bawaan mengoptimalkan proses pembuktian. Namun, setiap bukti dihitung dari tata letak. Untuk pekerjaan bukti tertentu, keuntungan dari fungsi bawaan akan sangat berkurang jika tata letaknya tidak efisien. Saat ini, ada sedikit daftar tata letak statis, dan setiap pembuktian dihitung berdasarkan tata letak yang paling sesuai dari daftar tersebut. Cara menyusun daftar statis ini memiliki dua kelemahan. Pertama, ada variasi tata letak yang terbatas. Ini tidak efisien untuk sebagian besar pekerjaan bukti dan menciptakan mekanisme biaya yang rumit yang membebankan biaya yang tidak perlu pada pengguna. Kedua, memelihara daftar secara manual itu sulit. Begitu jumlah builtin menjadi terlalu tinggi, perawatan manual menjadi sulit dan sebenarnya dapat menghambat proses pembuktian builtin yang efisien yang mendukung banyak nuansa. Untuk mengatasi masalah ini, tim StarkWare sedang mengembangkan sistem tata letak dinamis di mana tata letak dibuat khusus untuk setiap bukti kerja.
Tumpukan Kairo terbukti memfasilitasi komputasi tujuan umum dengan mengkompilasi kode Kairo menjadi instruksi untuk arsitektur CPU ramah-STARK: VM Kairo (selanjutnya disebut sebagai CVM). Banyak keuntungan dari CPU tujuan umum datang dengan biaya yang melekat, dan CVM tidak dioptimalkan untuk beberapa operasi umum. Fungsi hash Keccak, Pedersen, Poseidon adalah operasi umum seperti itu, seperti operasi kurva eliptik, pemeriksaan rentang (yaitu memeriksa apakah angka tertentu berada dalam rentang nilai tertentu), dan lain-lain.
Untuk mengatasi inefisiensi relatif CVM, tumpukan Kairo memperkenalkan konsep built-in untuk operasi kritis: plugin yang mengoptimalkan operasi semacam itu untuk membuktikan kompleksitas. Fungsi bawaan dapat dibandingkan dengan ASIC: ASIC adalah sirkuit terpadu khusus aplikasi, dan fungsi bawaan adalah kendala aljabar khusus aplikasi (AIR). Jika Anda tidak tahu atau tidak ingat apa itu AIR, secara singkat dibahas nanti di artikel ini; baca artikel ini untuk lebih jelasnya.
Singkatnya, kompleksitas bukti terkait (hampir linier) dengan sumber daya yang disebut unit pelacakan, dan fungsi bawaan menyederhanakan bukti operasi tertentu dengan menggunakan unit pelacakan yang jauh lebih sedikit daripada VM Kairo.
Sekarang manfaat dari fungsi bawaan telah dijelaskan, menjadi jelas mengapa fungsi bawaan dikembangkan untuk banyak operasi umum. Ini lebih mudah dikatakan daripada dilakukan. Proses memperkenalkan built-in baru ke dalam Starknet saat ini terdiri dari langkah-langkah berikut:
Menulis UDARA
Integrasikan dengan peribahasa dengan membuat tata letak baru (dijelaskan di bawah)
Mengintegrasikan ke dalam Starknet, yaitu memodifikasi basis kode dan alat pengembangnya untuk menggunakan fungsi bawaan yang baru
Selain tantangan menulis AIR, ada banyak ruang untuk perbaikan dalam dua fase yang tersisa. Artikel lanjutan ini akan menjelaskan secara lebih rinci fungsi bawaan AIR sebagai aplikasi khusus, masalah di atas, dan rencana masa depan.
Fungsi Bawaan: AIR Spesifik Aplikasi
AIR adalah singkatan dari Algebraic Intermediate Representation. Dalam artikel StarkWare ini dan lainnya, AIR adalah sistem polinomial untuk merepresentasikan mesin virtual. Misalnya, Kairo mengambil namanya dari CPU AIR: sistem polinomial yang mewakili arsitektur CPU tertentu. Solusi dari sistem polinomial ini mewakili transisi keadaan yang efisien, yang disebut lintasan eksekusi aljabar yang efisien (AET).
STARK membuktikan bahwa pengoperasian mesin virtual benar dengan membuktikan bahwa lintasan eksekusi yang sesuai dengan AIR yang diberikan adalah valid. Secara kasar, lintasan eksekusi adalah tabel angka, dan protokol STARK membuktikan bahwa angka-angka ini bersama-sama menyelesaikan sistem polinomial.
Operasi yang sama dapat dihitung dengan banyak cara, beberapa di antaranya lebih efisien. Dalam makalah ini, kompleksitas pembuktian pada dasarnya bergantung pada ukuran lintasan, yaitu jumlah sel lintasan dalam tabel. Karena jejak dihasilkan untuk AIR, AIR dirancang untuk aplikasi yang secara signifikan mengurangi jejak eksekusi untuk perhitungan tertentu. Fungsi bawaan adalah AIR khusus yang dioptimalkan untuk aplikasi.
Tabel di bawah menunjukkan peningkatan efisiensi untuk fungsi bawaan tertentu (semua dalam produksi).
Tata letak lintasan: sekarang dan masa depan
Seperti disebutkan sebelumnya, AET kira-kira adalah tabel angka yang merepresentasikan urutan langkah-langkah dalam mesin virtual berkode (yaitu, eksekusi program). Untuk menghitung bukti, pembukti menjalankan protokol STARK di jalur eksekusi AIR terkait.
Di atas, kami memperkenalkan fungsi bawaan sebagai AIR khusus aplikasi yang dirancang untuk meminimalkan kerumitan pembuktian dengan mengurangi jumlah unit jejak yang diperlukan untuk mengkodekan komputasi. Namun, jika fungsi bawaan terintegrasi secara acak di Starknet, banyak unit lintasan mungkin terbuang percuma, dan manfaat yang diharapkan akan berkurang. Mari kita jelaskan secara rinci di bawah ini.
Singkatnya, tata letak trek adalah penetapan sel trek ke "komponen" yang berbeda. Pada artikel ini, komponen tersebut adalah CVM dan fungsi bawaan. Secara khusus, tata letak menentukan jumlah relatif sel trek yang didapat setiap komponen. (Konstruk tata letak selalu digunakan untuk menyederhanakan validasi. Untuk mempelajari lebih lanjut, baca bagian "Kesederhanaan" di postingan ini).
Poin utamanya adalah bahwa kompleksitas bukti bergantung pada jumlah total sel trek yang dialokasikan oleh tata letak, dan alokasi sel trek mungkin lebih besar dari yang sebenarnya dibutuhkan. Misalnya, untuk mendemonstrasikan langkah pengurutan CVM, tata letak yang hanya menetapkan sel jejak ke komponen CVM kira-kira dua kali lebih efisien daripada tata letak yang menetapkan setengah dari sel jejak ke fungsi bawaan Poseidon. Kesimpulannya, tata letak yang sesuai dapat sangat mengurangi kerumitan pembuktian perhitungan tertentu.
Saat ini ada daftar tata letak yang dipelihara secara manual yang tumbuh dari waktu ke waktu karena dua alasan utama:
Fungsi bawaan hanya dapat digunakan untuk tata letak unit track yang ditetapkan padanya. Oleh karena itu, menambahkan built-in memerlukan setidaknya tata letak baru.
Tata letak yang disesuaikan untuk mengeksekusi kode Kairo mengoptimalkan alokasi sel. Oleh karena itu, pengoptimalan kasus penggunaan dalam sel sering kali memerlukan tata letak baru.
Kode untuk pembukti dan validator (validator Soliditas dan Kairo) dikonfigurasi sesuai dengan daftar tata letak.
Saat builtin Keccak dan Poseidon ditambahkan, menjadi semakin sulit untuk mempertahankan daftar tata letak yang cukup kecil untuk mengakomodasi banyak builtin dan membuat sebagian besar blok Starknet berjalan secara efisien. Selain itu, efisiensi diperkirakan akan turun secara signifikan saat built-in tambahan diperkenalkan, karena tata letak harus memperhitungkan banyak kemungkinan kombinasi dan rasio di antara built-in.
Tim StarkWare saat ini sedang berupaya meningkatkan sistem dengan membuang daftar tata letak yang telah dibuat sebelumnya demi "tata letak dinamis", yang merupakan penyesuaian instan untuk setiap eksekusi kode Kairo. Tata Letak Dinamis akan selalu melakukan alokasi dengan proporsi terbaik untuk tugas verifikasi yang ada. Dari sudut pandang teknik, mendukung pengetikan dinamis akan membutuhkan banyak perubahan pada basis kode. Namun, tim StarkWare berharap dapat menyederhanakan lapisan bukti Starknet dengan memanfaatkan tata letak dinamis, pemanfaatan unit lintasan yang lebih baik, dan pemanfaatan pembuktian yang lebih baik.
Dengan tata letak yang dinamis, kerumitan pemeliharaan banyak perangkat bawaan menghilang secara manual, menyederhanakan proses pengintegrasian lebih banyak perangkat bawaan baru ke dalam Starknet.
Tata Letak dan Biaya Dinamis
Salah satu tujuan dari biaya transaksi adalah membebankan biaya protokol marjinal kepada pengguna yang dikeluarkan oleh transaksi. Karena satuan biaya transaksi adalah mata uang, mekanisme biaya melibatkan konversi dari sumber daya (misalnya langkah mesin virtual, fungsi bawaan, calldata, gas Ethereum) ke token (misalnya STRK, ETH).
Saat ini, karena prover membebankan biaya berdasarkan total jejak daripada rasio pemanfaatan, sumber daya yang terbuang ditanggung oleh pengguna. Tata letak dinamis akan meningkatkan penggunaan unit track, sehingga mengurangi pembebanan biaya transaksi yang "tidak perlu" (termasuk konsumsi sumber daya yang tidak secara langsung disebabkan oleh transaksi pengguna).
Integrasi fungsi bawaan Starknet
Pada titik ini, integrasi fungsi bawaan adalah langkah terakhir, yaitu memodifikasi basis kode Starknet untuk mewujudkan penggunaan praktis. Tingkat modifikasi kode terkait dengan aplikasi tata letak, dan kode perlu dimodifikasi untuk memastikan bahwa sistem operasi Starknet memanggil fungsi bawaan jika memungkinkan. Misalnya, sistem operasi Starknet memanggil fungsi hash Poseidon selama eksekusi kode Kairo, dan pada saat yang sama memanggil fungsi bawaan Poseidon.
Mirip dengan tata letak, bawaan Starknet sekarang dapat didukung secara manual. Namun, berbeda dengan kasus tata letak, dukungan manual ini bukanlah penghalang untuk integrasi meskipun terdapat banyak fungsi bawaan. Dengan kata lain, dukungan bawaan Starknet bukanlah halangan untuk integrasi, tata letak dinamis benar-benar akan membuka jalan untuk membuat dan mengintegrasikan bawaan tambahan.
Ringkas
Dalam artikel ini kami menjelaskan apa itu fungsi bawaan, manfaatnya, tantangan yang ada, dan rencana StarkWare. Fokus saat ini adalah tata letak dinamis, yang tidak hanya akan meningkatkan efisiensi proses bukti, tetapi juga memfasilitasi integrasi built-in baru.
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Manfaat dan Tantangan Fungsi Bawaan Starknet
Asli: Tata Letak Bawaan dan Dinamis
Terjemahan dan pengoreksian: "Komunitas Tionghoa StarkNet"
Ringkasan
Fungsi bawaan mengoptimalkan proses pembuktian. Namun, setiap bukti dihitung dari tata letak. Untuk pekerjaan bukti tertentu, keuntungan dari fungsi bawaan akan sangat berkurang jika tata letaknya tidak efisien. Saat ini, ada sedikit daftar tata letak statis, dan setiap pembuktian dihitung berdasarkan tata letak yang paling sesuai dari daftar tersebut. Cara menyusun daftar statis ini memiliki dua kelemahan. Pertama, ada variasi tata letak yang terbatas. Ini tidak efisien untuk sebagian besar pekerjaan bukti dan menciptakan mekanisme biaya yang rumit yang membebankan biaya yang tidak perlu pada pengguna. Kedua, memelihara daftar secara manual itu sulit. Begitu jumlah builtin menjadi terlalu tinggi, perawatan manual menjadi sulit dan sebenarnya dapat menghambat proses pembuktian builtin yang efisien yang mendukung banyak nuansa. Untuk mengatasi masalah ini, tim StarkWare sedang mengembangkan sistem tata letak dinamis di mana tata letak dibuat khusus untuk setiap bukti kerja.
Tumpukan Kairo terbukti memfasilitasi komputasi tujuan umum dengan mengkompilasi kode Kairo menjadi instruksi untuk arsitektur CPU ramah-STARK: VM Kairo (selanjutnya disebut sebagai CVM). Banyak keuntungan dari CPU tujuan umum datang dengan biaya yang melekat, dan CVM tidak dioptimalkan untuk beberapa operasi umum. Fungsi hash Keccak, Pedersen, Poseidon adalah operasi umum seperti itu, seperti operasi kurva eliptik, pemeriksaan rentang (yaitu memeriksa apakah angka tertentu berada dalam rentang nilai tertentu), dan lain-lain.
Untuk mengatasi inefisiensi relatif CVM, tumpukan Kairo memperkenalkan konsep built-in untuk operasi kritis: plugin yang mengoptimalkan operasi semacam itu untuk membuktikan kompleksitas. Fungsi bawaan dapat dibandingkan dengan ASIC: ASIC adalah sirkuit terpadu khusus aplikasi, dan fungsi bawaan adalah kendala aljabar khusus aplikasi (AIR). Jika Anda tidak tahu atau tidak ingat apa itu AIR, secara singkat dibahas nanti di artikel ini; baca artikel ini untuk lebih jelasnya.
Singkatnya, kompleksitas bukti terkait (hampir linier) dengan sumber daya yang disebut unit pelacakan, dan fungsi bawaan menyederhanakan bukti operasi tertentu dengan menggunakan unit pelacakan yang jauh lebih sedikit daripada VM Kairo.
Sekarang manfaat dari fungsi bawaan telah dijelaskan, menjadi jelas mengapa fungsi bawaan dikembangkan untuk banyak operasi umum. Ini lebih mudah dikatakan daripada dilakukan. Proses memperkenalkan built-in baru ke dalam Starknet saat ini terdiri dari langkah-langkah berikut:
Menulis UDARA
Integrasikan dengan peribahasa dengan membuat tata letak baru (dijelaskan di bawah)
Mengintegrasikan ke dalam Starknet, yaitu memodifikasi basis kode dan alat pengembangnya untuk menggunakan fungsi bawaan yang baru
Selain tantangan menulis AIR, ada banyak ruang untuk perbaikan dalam dua fase yang tersisa. Artikel lanjutan ini akan menjelaskan secara lebih rinci fungsi bawaan AIR sebagai aplikasi khusus, masalah di atas, dan rencana masa depan.
Fungsi Bawaan: AIR Spesifik Aplikasi
AIR adalah singkatan dari Algebraic Intermediate Representation. Dalam artikel StarkWare ini dan lainnya, AIR adalah sistem polinomial untuk merepresentasikan mesin virtual. Misalnya, Kairo mengambil namanya dari CPU AIR: sistem polinomial yang mewakili arsitektur CPU tertentu. Solusi dari sistem polinomial ini mewakili transisi keadaan yang efisien, yang disebut lintasan eksekusi aljabar yang efisien (AET).
STARK membuktikan bahwa pengoperasian mesin virtual benar dengan membuktikan bahwa lintasan eksekusi yang sesuai dengan AIR yang diberikan adalah valid. Secara kasar, lintasan eksekusi adalah tabel angka, dan protokol STARK membuktikan bahwa angka-angka ini bersama-sama menyelesaikan sistem polinomial.
Operasi yang sama dapat dihitung dengan banyak cara, beberapa di antaranya lebih efisien. Dalam makalah ini, kompleksitas pembuktian pada dasarnya bergantung pada ukuran lintasan, yaitu jumlah sel lintasan dalam tabel. Karena jejak dihasilkan untuk AIR, AIR dirancang untuk aplikasi yang secara signifikan mengurangi jejak eksekusi untuk perhitungan tertentu. Fungsi bawaan adalah AIR khusus yang dioptimalkan untuk aplikasi.
Tabel di bawah menunjukkan peningkatan efisiensi untuk fungsi bawaan tertentu (semua dalam produksi).
Tata letak lintasan: sekarang dan masa depan
Seperti disebutkan sebelumnya, AET kira-kira adalah tabel angka yang merepresentasikan urutan langkah-langkah dalam mesin virtual berkode (yaitu, eksekusi program). Untuk menghitung bukti, pembukti menjalankan protokol STARK di jalur eksekusi AIR terkait.
Di atas, kami memperkenalkan fungsi bawaan sebagai AIR khusus aplikasi yang dirancang untuk meminimalkan kerumitan pembuktian dengan mengurangi jumlah unit jejak yang diperlukan untuk mengkodekan komputasi. Namun, jika fungsi bawaan terintegrasi secara acak di Starknet, banyak unit lintasan mungkin terbuang percuma, dan manfaat yang diharapkan akan berkurang. Mari kita jelaskan secara rinci di bawah ini.
Singkatnya, tata letak trek adalah penetapan sel trek ke "komponen" yang berbeda. Pada artikel ini, komponen tersebut adalah CVM dan fungsi bawaan. Secara khusus, tata letak menentukan jumlah relatif sel trek yang didapat setiap komponen. (Konstruk tata letak selalu digunakan untuk menyederhanakan validasi. Untuk mempelajari lebih lanjut, baca bagian "Kesederhanaan" di postingan ini).
Poin utamanya adalah bahwa kompleksitas bukti bergantung pada jumlah total sel trek yang dialokasikan oleh tata letak, dan alokasi sel trek mungkin lebih besar dari yang sebenarnya dibutuhkan. Misalnya, untuk mendemonstrasikan langkah pengurutan CVM, tata letak yang hanya menetapkan sel jejak ke komponen CVM kira-kira dua kali lebih efisien daripada tata letak yang menetapkan setengah dari sel jejak ke fungsi bawaan Poseidon. Kesimpulannya, tata letak yang sesuai dapat sangat mengurangi kerumitan pembuktian perhitungan tertentu.
Saat ini ada daftar tata letak yang dipelihara secara manual yang tumbuh dari waktu ke waktu karena dua alasan utama:
Fungsi bawaan hanya dapat digunakan untuk tata letak unit track yang ditetapkan padanya. Oleh karena itu, menambahkan built-in memerlukan setidaknya tata letak baru.
Tata letak yang disesuaikan untuk mengeksekusi kode Kairo mengoptimalkan alokasi sel. Oleh karena itu, pengoptimalan kasus penggunaan dalam sel sering kali memerlukan tata letak baru.
Kode untuk pembukti dan validator (validator Soliditas dan Kairo) dikonfigurasi sesuai dengan daftar tata letak.
Saat builtin Keccak dan Poseidon ditambahkan, menjadi semakin sulit untuk mempertahankan daftar tata letak yang cukup kecil untuk mengakomodasi banyak builtin dan membuat sebagian besar blok Starknet berjalan secara efisien. Selain itu, efisiensi diperkirakan akan turun secara signifikan saat built-in tambahan diperkenalkan, karena tata letak harus memperhitungkan banyak kemungkinan kombinasi dan rasio di antara built-in.
Tim StarkWare saat ini sedang berupaya meningkatkan sistem dengan membuang daftar tata letak yang telah dibuat sebelumnya demi "tata letak dinamis", yang merupakan penyesuaian instan untuk setiap eksekusi kode Kairo. Tata Letak Dinamis akan selalu melakukan alokasi dengan proporsi terbaik untuk tugas verifikasi yang ada. Dari sudut pandang teknik, mendukung pengetikan dinamis akan membutuhkan banyak perubahan pada basis kode. Namun, tim StarkWare berharap dapat menyederhanakan lapisan bukti Starknet dengan memanfaatkan tata letak dinamis, pemanfaatan unit lintasan yang lebih baik, dan pemanfaatan pembuktian yang lebih baik.
Dengan tata letak yang dinamis, kerumitan pemeliharaan banyak perangkat bawaan menghilang secara manual, menyederhanakan proses pengintegrasian lebih banyak perangkat bawaan baru ke dalam Starknet.
Tata Letak dan Biaya Dinamis
Salah satu tujuan dari biaya transaksi adalah membebankan biaya protokol marjinal kepada pengguna yang dikeluarkan oleh transaksi. Karena satuan biaya transaksi adalah mata uang, mekanisme biaya melibatkan konversi dari sumber daya (misalnya langkah mesin virtual, fungsi bawaan, calldata, gas Ethereum) ke token (misalnya STRK, ETH).
Saat ini, karena prover membebankan biaya berdasarkan total jejak daripada rasio pemanfaatan, sumber daya yang terbuang ditanggung oleh pengguna. Tata letak dinamis akan meningkatkan penggunaan unit track, sehingga mengurangi pembebanan biaya transaksi yang "tidak perlu" (termasuk konsumsi sumber daya yang tidak secara langsung disebabkan oleh transaksi pengguna).
Integrasi fungsi bawaan Starknet
Pada titik ini, integrasi fungsi bawaan adalah langkah terakhir, yaitu memodifikasi basis kode Starknet untuk mewujudkan penggunaan praktis. Tingkat modifikasi kode terkait dengan aplikasi tata letak, dan kode perlu dimodifikasi untuk memastikan bahwa sistem operasi Starknet memanggil fungsi bawaan jika memungkinkan. Misalnya, sistem operasi Starknet memanggil fungsi hash Poseidon selama eksekusi kode Kairo, dan pada saat yang sama memanggil fungsi bawaan Poseidon.
Mirip dengan tata letak, bawaan Starknet sekarang dapat didukung secara manual. Namun, berbeda dengan kasus tata letak, dukungan manual ini bukanlah penghalang untuk integrasi meskipun terdapat banyak fungsi bawaan. Dengan kata lain, dukungan bawaan Starknet bukanlah halangan untuk integrasi, tata letak dinamis benar-benar akan membuka jalan untuk membuat dan mengintegrasikan bawaan tambahan.
Ringkas
Dalam artikel ini kami menjelaskan apa itu fungsi bawaan, manfaatnya, tantangan yang ada, dan rencana StarkWare. Fokus saat ini adalah tata letak dinamis, yang tidak hanya akan meningkatkan efisiensi proses bukti, tetapi juga memfasilitasi integrasi built-in baru.