Tanda tangan BLS ada di mana-mana, mulai dari konsensus Ethereum hingga EigenLayer. Tapi mudah untuk menggunakannya secara salah. Apa itu tanda tangan BLS? Mari kita bicara tentang cara yang benar dan cara yang salah untuk menggunakannya:

Tapi pertama-tama, apa itu tanda tangan BLS? Tanda tangan BLS adalah primitif kriptografi yang digunakan untuk menandatangani pesan, seperti ECDSA. Inilah cara kerja matematika. Itu dibangun di atas pasangan kurva elips. Tapi apa yang membuat mereka begitu istimewa? Mengapa menggunakan pasangan mewah ini?

Fitur pembunuh BLS: agregasi tanda tangan. Anda dapat menggabungkan banyak tanda tangan BLS menjadi satu tanda tangan. Ini memungkinkan Anda mengirimkan dan memeriksa tanda tangan N sekaligus, lebih hemat ruang dan waktu! Dan on-chain, pengoptimalan sangat penting untuk penghematan gas.

Untuk melihat secara mendalam tentang cara kerja tanda tangan BLS, bersama dengan proses pembuatan agregasi dan multi-tanda tangan, lihat posting blog lengkap yang ditautkan di akhir utas ini! Sekarang, mari kita lihat bagaimana tanda tangan BLS bisa salah, dan bagaimana EigenLayer menggunakannya (dengan benar, menghindari jebakan ini)!

EigenLayer adalah lapisan pengambilan ulang untuk Ethereum. Di EigenLayer AVSes, validator menandatangani hasil perhitungan validasi mereka. Agregator mengumpulkan semua tanda tangan ini dan mendorongnya secara berantai. Tanda tangan agregat diverifikasi secara on-chain.

Tugas berisi nomor blok saat tugas dibuat dan ambang batas yang menunjukkan persentase validasi operator, yang diperlukan untuk memvalidasi tugas. Operator yang memilih AVS dapat mendapatkan tugas tersebut untuk menghitung jawaban tugas dan kemudian operator dapat mengirim jawaban dengan tanda tangan tugas BLS mereka ke agregator. Segera setelah ambang batas jawaban identik tercapai, agregator menggabungkan semua tanda tangan BLS menjadi tanda tangan agregat unik dan mengirimkannya kembali ke kontrak AVS. Kontrak memverifikasi bahwa tanda tangan sudah benar dan membuka periode yang menantang ketika penantang dapat memberikan bukti bahwa validasi itu salah, dan jika demikian, operator yang berperilaku buruk dipotong.

Dalam kontrak, verifikasi terjadi di fungsi 'trySignatureAndApkVerification':

Namun, multi-tanda tangan, jika digunakan secara tidak benar, datang dengan masalah serius yang disebut serangan kunci nakal. Katakanlah pengguna yang jujur memiliki kunci publik, 'pk_0'. Penyerang yang sebelumnya telah melihat 'pk_0' dapat memilih kunci publik mereka sebagai pk_1 = sk_1⋅G_1—pk_0. Penyerang tidak akan mengetahui kunci pribadi yang terkait dengan kunci publik. Namun, verifikasi multi-tanda tangan akan memberikan yang berikut:

Hanya 'sk_1' yang diperlukan untuk menandatangani pesan yang menghasilkan multi-tanda tangan yang valid, meskipun pengguna pertama mungkin belum menandatanganinya. Ini dengan mudah digeneralisasikan ke angka 'r' pengguna jujur dengan memilih kunci nakal, yaitu:

Ini adalah ancaman berbahaya karena, dalam contoh AVS kami sebelumnya, agregator jahat yang sebelumnya akan mendaftarkan kunci nakal dapat mengirim tanda tangan agregat yang tidak ditandatangani oleh validator tetapi tetap diterima oleh kontrak. Ini akan menyebabkan validator dipotong bahkan jika mereka tidak berperilaku buruk.

Jadi, untuk mencegah serangan kunci nakal, metode umum adalah meminta pengguna untuk membuktikan bahwa mereka tahu kunci pribadi cocok dengan kunci publik mereka, yang dikenal sebagai bukti kepemilikan. Dengan demikian, pada langkah pendaftaran pertama, pengguna diminta untuk mendaftarkan kunci publik mereka bersama dengan bukti kepemilikan π sehingga:

Pada dasarnya, pengguna diminta untuk menandatangani kunci publik mereka atau pesan identifikasi lainnya. Di AVS, pesan adalah alamat operator. Dalam kontrak EigenLayer, bukti kepemilikan diverifikasi oleh fungsi 'registerBLSPublicKey':

Fungsi 'pubkeyRegistrationMessageHash' digunakan untuk melakukan hash pada pemisah domain kustom 'PUBKEY_REGISTRATION_TYPEHASH' dan alamat operator.

Setelah pendaftaran, kunci publik ditambahkan ke kontrak. Kita dapat memverifikasi nilainya dengan memanggil fungsi 'getRegisteredPubkey'. Berikut adalah contoh kunci publik BLS yang terdaftar untuk EigenDA AVS:

Bukti kepemilikan pada dasarnya adalah tanda tangan BLS. Namun, juga tidak disarankan untuk menggunakan multi-tanda tangan selama langkah bukti kepemilikan, misalnya, untuk mendaftarkan beberapa kunci publik untuk satu peserta. Jika demikian, peserta akan mencapai serangan splitting-zero. Dalam hal ini, peserta dapat mendaftarkan kunci yang akan dibatalkan saat dijumlahkan dan dapat melewati bukti kepemilikan.

Kami telah melihat bahwa multi-tanda tangan BLS menawarkan peluang pengoptimalan yang signifikan. Implementasi EigenLayer menunjukkan kekuatan tanda tangan BLS dan juga menyoroti kompleksitas yang terlibat dalam penerapan praktisnya. Namun, multi-tanda tangan menimbulkan risiko keamanan seperti serangan kunci nakal, yang memerlukan perlindungan seperti bukti kepemilikan. Tetapi dengan peningkatan Pectra yang mendukung BLS12-381, kita mungkin melihat implementasi dan peningkatan lebih lanjut di Solidity, dan dengan demikian kami berharap posting ini membantu menghindari bug dan kerentanan implementasi yang diketahui.

Untuk menyelami lebih dalam tanda tangan BLS, agregasi bangunan, dan multi-tanda tangan, lihat posting blog kami yang baru-baru ini diterbitkan di bawah ini: