Dev. Pembaruan Team Sprint 28

Implementasi Fungsionalitas

Menerapkan bukti konsep pembuatan kode QR #1229

Implementasi PoC dari 2 kode QR yang dihasilkan menggunakan dua API di dalam Agora. API pertama mengembalikan data yang akan diberikan untuk login, yang kedua untuk kunci enkripsi. Selain itu, parameter kueri telah digunakan untuk parameter.

• Buat alat (atau perluas agora-cli) untuk mensimulasikan aktivitas di jaringan Agora #1227

Kami ingin mulai menguji Agora di lingkungan yang mensimulasikan jaringan dunia nyata. Anda mungkin menganggap ini sebagai TestNet, namun, sistem node ini tidak perlu dipublikasikan – oleh karena itu tidak perlu TestNet. Ini bisa berupa jaringan apa pun dengan blok genesis yang ditentukan khusus. Misalnya, ini bisa menjadi jaringan node Agora yang berjalan hanya di komputer pengembang untuk waktu yang singkat. Atau dapat berjalan pada layanan cloud khusus yang hanya dapat kami akses.

Tepat di mana jaringan berjalan tidak penting untuk masalah ini.

Sebelumnya, kami hanya mendapat dukungan untuk:

• Memulai node Agora baru (buruh pelabuhan)
• Membuat transaksi dan mengirimkannya ke node Agora (agora-cli #206)

Untuk mensimulasikan jaringan sepenuhnya, kami juga memerlukan beberapa fitur tambahan:

• Kemampuan untuk terus menghasilkan transaksi baru yang valid dan mengirimkannya ke satu (atau lebih) node Agora
• Kemampuan untuk dengan sengaja melakukan DDoS pada node Agora dengan permintaan API yang terbentuk dengan baik. Permintaan ini berisi parameter yang valid (misalnya transaksi yang valid)
• Kemampuan untuk dengan sengaja melakukan DDoS pada node Agora dengan permintaan API yang salah. Ini akan membutuhkan penggunaan keacakan. Misalnya, alat tersebut dapat mencoba membalik bit acak atau mengirim data sampah ke titik akhir API. Alat tersebut juga dapat mencoba memanggil titik akhir yang tidak ada. Node Agora harus menangani semua kasus ini dengan benar.

Tujuan alat ini adalah untuk:

• Temukan bug tersembunyi yang dapat menyebabkan simpul Agora menjadi rusak. Penting untuk menangkap sebanyak mungkin bug ini sebelum CoinNet diterapkan.
• Temukan hambatan kinerja, dan kemudian optimalkan Agora.

Sebagai pengembang, tujuan kami adalah:

• Temukan serangkaian fitur bagus yang harus didukung alat ini dan kasus penggunaan untuk fitur semacam itu. Beberapa di antaranya tercantum di atas.
• Terapkan fitur tersebut. Jika cakupan penerapan fitur terlalu besar, silakan uraikan menjadi beberapa masalah kecil.

Refactor the testsuite untuk memulai dengan test block #1176

Sebelumnya, saat memulai test-suite (localrest) kami akan menentukan jumlah node. Ini berarti agora.test.Base diperlukan untuk membuat blok genesis yang berbeda per pengujian. Kami tidak yakin ini adalah sesuatu yang kami butuhkan. Jika pengujian perlu mendukung sejumlah validator tertentu, kami cukup menyediakan fungsi untuk memajukan blockchain ke siklus pendaftaran berikutnya, yang dapat menjadi apa pun yang kami inginkan.

Penelitian & pengembangan lapisan flash #1266

Masalah ini dibuat sebagai masalah berkelanjutan yang akan terus ditangani sebagai kemajuan penelitian dan pengembangan. Konten dalam masalah ini akan terus berkembang tetapi berikut ini adalah fokus kami saat ini.

Ringkasan tingkat tinggi

Kami ingin membangun solusi lapis kedua untuk membuat Agora dapat diskalakan dan memungkinkan pembayaran mikro.

Tujuan

Kami memiliki setidaknya tujuan berikut:

• Skala ke banyak txs / dtk
• Aktifkan transaksi berbiaya rendah
• Aktifkan pembayaran cepat & transaksi mikro (menyiratkan biaya rendah)
• Menjalankan node Flash seharusnya aman. Pencadangan / pemulihan seharusnya tidak menyebabkan hukuman yang tidak diinginkan.

Persyaratan

• Perlu menerapkan mesin eksekusi dasar. P2SH, mungkin mirip dengan Bitcoin dengan skrip Locking, Redeem, dan Unlocking-nya (lihat https://cypherpunks-core.github.io/bitcoinbook/ch07.html#with_p2sh).
• Perlu menerapkan HTLC untuk mengaktifkan pembayaran multi-hop.

Insentif validator flash

Perlu ada insentif bagi validator untuk menjadi bagian dari lapisan flash. Apa pun yang dipertaruhkan lebih dari 40k akan digunakan untuk membuat saluran, kami perlu memberi insentif kepada operator untuk mempertaruhkan lebih banyak.

Script support

• BIP 16 — Pay to Script Hash: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
• BIP 65 — CHECKLOCKTIMEVERIFY: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
• BIP 118 — SIGHASH_NOINPUT (Draft, Outdated): https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
• Updated BIP 118 — SIGHASH_ANYPREVOUT (Draft): https://github.com/bitcoin/bips/blob/c7c6a58b7a66a5dc5f4435319577d26a34082a79/bip-0118.mediawiki
• BIP 141 — Segregated Witness: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
• BIP 114 — MAST: https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki

LN-Penalti vs Eltoo

Pahami bahwa saat ini Lightning Network sebenarnya adalah kumpulan protokol. Eltoo adalah implementasi lapisan Pembaruan bersaing yang memiliki banyak manfaat dibandingkan LN-Penalty. Lihat gambar ini: https://blockstream.com/img/blog/2018-04-30/lightning-layers.png

LN-Penalti

• Memulihkan node yang dicadangkan dapat menyebabkan hukuman mandiri tanpa pengawasan. Node menerbitkan status lama, counterparty menerbitkan hukuman tx. Operator node kehilangan semua dana. Pengembang petir mengalaminya sendiri, mudah untuk membuat kesalahan.
• Terlalu banyak risiko karena I / O bisa gagal.
• Tidak dapat dengan mudah menjalankan node cadangan! Node harus tetap sinkron setiap saat.
• Banyak sekali manajemen negara. Semua hukuman txs perlu disimpan dalam memori jika rekanan menerbitkan update tx yang lebih lama.
• Keadaan asimetris yang perlu dirahasiakan.

Eltoo

• Tidak ada sistem penalti
• “Hukuman” untuk mencoba menyelesaikan transaksi sebelumnya adalah biaya yang dibayarkan untuk memasukkan transaksi tersebut. Tetapi tx ini kemudian dapat diganti dengan tx pembaruan yang lebih baru.
• Keadaan simetris
• Apalagi manajemen negara. Hanya simpan pembaruan & penyelesaian terakhir.
• Mengaktifkan saluran multi-partai. Ini bisa bekerja sangat baik dengan sistem PoS kami.
• Transaksi pemicu (disebutkan nanti di whitepaper) memungkinkan pembuatan saluran dengan umur yang panjang.
• Membutuhkan SIGHASH_NOINPUT – BIP 118
• Mengikat melalui kompatibilitas skrip, bukan melalui UTXO
• Biaya dapat ditetapkan nanti, bukan di muka. Dan mereka bisa diganti. Ini penting untuk saluran yang berjalan lama.
• Membutuhkan tag urutan yang meningkat secara monoton, untuk mendapatkan pasangan kunci dari dan mengelola pembaruan tx mana yang lebih baru. Dalam Bitcoin mereka menggunakan kembali nLockTime dengan nilai di masa lalu, ini dimungkinkan karena nLockTime saat ini sudah tinggi. Idealnya kami harus menerapkan nomor urut yang berbeda (juga direkomendasikan di whitepaper Eltoo).
• Pembaruan skrip mengikat ke nomor urut.
• Dengan menggunakan Schnorr kita mungkin dapat menyandikan derivasi kunci publik secara langsung dalam skrip dengan menjadikannya opcode.
• Merilis skrip pembaruan awal tidak berarti apa-apa, itu masih terikat ke skrip pembaruan berikutnya.

• Sumber daya pengetahuan

Bab Menguasai skrip Bitcoin (disarankan): https://cypherpunks-core.github.io/bitcoinbook/ch07.html

Sumber daya Eltoo

• https://blockstream.com/2018/04/30/en-eltoo-next-lightning/
• https://blockstream.com/eltoo.pdf
• https://www.youtube.com/watch?v=HauP9F16mUM
• https://www.youtube.com/watch?v=3ZjymCOmn_A
• https://www.youtube.com/watch?v=PUDWGH_MvmQ

Prototipe Eltoo

• Prototipe yang hanya dikenal: https://github.com/remyers/signet2/blob/eltoo/test/functional/simulate_eltoo.py

Nekat

Mungkin sebaiknya tidak memotong lebih dari 40k. Jika sebuah node benar-benar terpotong, penandatangan saluran lain dengan node tersebut perlu mempublikasikan penyelesaian terakhir mereka yang diketahui sehingga mereka dapat memperoleh pengembalian dana.

Pengembangan Berkelanjutan

• Basic script execution engine #237
• Flash layer research & development #1266 (Continued)
• Add a way to store data in a block #1214
• Sending blocks to Stoa failed on live system #165
• Design & implement slashing rules for missing pre-images #1076
• Use a deployment based enum in the node configuration to indicate the genesis block to use. #1244

Website(Kor): https://bosagora.io/ko
Website(Eng): https://bosagora.io
Telegram(Kor): https://t.me/bpf_korea
Telegram(Eng): https://t.me/bpf_eng
BOSAGORA Official Announcement: https://t.me/boa_announcement
Medium: medium.com/bosagora
Twitter: https://twitter.com/BOSAGORA1
Reddit: https://www.reddit.com/r/BOSAGORA_BOA/
Facebook: https://www.facebook.com/BOSAGORA/
Linkedin: https://www.linkedin.com/company/bpf-korea/
Youtube: http://bit.ly/2YFpd5r
Github: https://github.com/bpfkorea