T-Fi, Model Ekonomi Generasi Berikutnya, Penggantian Transaksi & Perbaikan Alat Pemantauan, dll
Pengembangan
Februari adalah bulan yang singkat, tetapi bukan berarti tidak produktif. Bulan lalu justru sebaliknya bagi tim BOSAGORA. Perkembangan terbesar yang terjadi pada bulan Februari adalah penyelesaian protokol pemotongan kami. Protokol pemotongan Agora sekarang disiapkan untuk menghukum pengguna yang berperilaku tidak semestinya di platform Agora dengan tepat.
Berikut rangkuman kegiatan pembangunan bulan lalu dan item-item yang saat ini masih dalam pengembangan:
Pengembangan Inti di Feb:
Aktivitas Bulanan:
Bulan lalu kami memiliki 71 permintaan tarik terkait Agora dan 71 masalah aktif. Di antaranya:
- 60 permintaan tarik dibuka
- 11 permintaan tarik digabung
- 35 edisi baru
- 36 masalah ditutup
Fungsionalitas Dikembangkan:
Menerapkan saluran pembayaran tidak langsung melalui HTLC #1419 (Saluran Pembayaran, Fitur)
Ini dikerjakan oleh Drey. Untuk membuat lapisan Flash nyaman digunakan dan lebih skalabel, kita perlu mengaktifkan perutean pembayaran melalui saluran tidak langsung.
Misalnya, pertimbangkan kasus dengan saluran berikut:
- Alice <=> Bob <=> Charlie <=> Dylan
Dalam tata letak saluran ini Alice hanya dapat mengirim transaksi kilat ke Bob, dan dia tidak dapat mengirimnya ke Charlie atau Dylan. Alice perlu membuka saluran baru untuk Charlie dan Dylan.
Namun, ini merepotkan karena:
- Ini meningkatkan jumlah transaksi on-chain
- Ini meningkatkan jumlah pembukuan yang perlu dilakukan Alice
- Ini menunda semua transaksi mikro sampai transaksi saluran terbuka dieksternalisasi
- Ini menyebabkan biaya tambahan untuk semua pihak yang terlibat
Kita harus mendukung saluran pembayaran tidak langsung melalui penggunaan Kontrak Terkunci Waktu Hashed. Penjelasan singkat HTLC di saluran pembayaran disediakan di sini: https://hackernoon.com/what-are-hashed-timelock-contracts-htlcs-application-in-lightning-network-payment-channels-14437eeb9345
Mesin eksekusi kami sudah mendukung HTLC seperti yang ditunjukkan di sini serta timelock. Kami dapat menggunakannya di lapisan Flash kami untuk menerapkan saluran pembayaran tidak langsung.
Definisi selesai:
- Alice dapat mengirim transaksi mikro ke Dylan melalui saluran perantara
- Saluran flash tidak ditutup sampai semua HTLC diselesaikan
- Ada batasan untuk penundaan HTLC yang dapat diterima. Misalnya. Bob dapat memutuskan untuk menolak HTLC jika dia adalah perantara
- Mengklaim HTLC harus otomatis
Silakan merujuk ke tautan Github di bawah ini untuk informasi lebih lanjut:
https://github.com/bpfkorea/agora/issues/1419
Menerapkan bukti konsep Eltoo #1267 (Saluran Pembayaran, Fitur)
Ini dikerjakan oleh Drey. Seperti disebutkan dalam #1266, saat ini ada dua mekanisme pembaruan LN kompetitif utama. LN-Penalty, dan Eltoo. LN-Penalty memiliki tiga implementasi yang kompatibel, sedangkan Eltoo masih diblokir untuk dikembangkan & digunakan pada Bitcoin karena persyaratan untuk jenis sighash baru (BIP 118).
Pengembang LN tampaknya setuju bahwa Eltoo adalah evolusi besar atas LN-Penalti, dan mungkin akan mengganti protokol pembaruan penalti. Perhatikan bahwa kedua protokol dapat digunakan secara bersamaan di Bitcoin.
Dalam kasus kami, kami memiliki keuntungan besar atas Bitcoin. Kita bisa mengembangkan protokol tanpa terhalang oleh keharusan melakukan soft-fork. Selain itu, sistem PoS kami berpotensi memudahkan pembuatan saluran multi-pihak – kami bahkan dapat menjadikan pembuatan saluran multi-pihak ini menjadi bagian dari aturan protokol (pikirkan pengacakan kuorum, misalnya).
Sebagai langkah awal kita dapat mencoba menerapkan bukti konsep Eltoo. Ada banyak bagian yang bergerak, dan kita harus berusaha mendapatkan bukti konsep yang paling sederhana.
Ini mungkin membutuhkan yang berikut:
- Menerapkan bidang saksi (skrip)
- Menerapkan mesin eksekusi berbasis tumpukan yang sangat sederhana dengan hanya opcode yang diperlukan (misalnya kunci waktu, pencocokan urutan)
- Menerapkan nomor urut untuk pencocokan skrip (ini bahkan mungkin dioptimalkan nanti dengan trik schnorr, saya perlu bereksperimen)
- Tambahkan dukungan untuk sighash_noinput
- Tambahkan dukungan HTLC untuk pembayaran multi-hop
- Alokasikan lebih dari> 40 ribu dana untuk pembuatan saluran
Silakan merujuk ke tautan Github di bawah ini untuk informasi lebih lanjut:
https://github.com/bpfkorea/agora/issues/1267
Lapisan IFlash: Menerapkan perutean terenkripsi bawang #1529 (Saluran Pembayaran, Fitur)
Ini dikerjakan oleh Drey. Kami menerapkan sesuatu yang mirip dengan berikut ini di protokol Flash kami.
Paket pembayaran yang digunakan untuk perutean disebut “onion”.
Mari kita gunakan analogi bawang untuk mengikuti pembayaran yang diarahkan. Pada rutenya dari pengirim pembayaran (pembayar) ke tujuan pembayaran (penerima pembayaran), bawang merah diteruskan dari node ke node di sepanjang jalur. Pengirim membangun seluruh bawang, dari tengah ke luar. Pertama, pengirim membuat informasi pembayaran untuk penerima (akhir) pembayaran dan mengenkripsinya dengan lapisan enkripsi yang hanya dapat didekripsi oleh penerima. Kemudian, pengirim membungkus lapisan tersebut dengan instruksi untuk node di jalur tepat sebelum penerima akhir dan mengenkripsi dengan lapisan yang hanya dapat didekripsi oleh node tersebut.
Lapisan dibangun dengan instruksi yang bekerja mundur sampai seluruh jalur dikodekan dalam lapisan. Pengirim kemudian memberikan bawang lengkap ke node pertama di jalur yang hanya dapat membaca lapisan terluar. Setiap node mengupas lapisan, dan menemukan petunjuk di dalamnya yang mengungkapkan node berikutnya di jalur dan meneruskan bawang. Karena setiap simpul mengupas satu lapisan, ia tidak dapat membaca sisa bawang. Yang diketahui hanyalah dari mana bawang itu berasal dan kemana perginya selanjutnya, tanpa ada indikasi siapa pengirim asli atau penerima akhir.
Ini berlanjut hingga bawang merah mencapai tujuan pembayaran (penerima pembayaran). Kemudian, node tujuan membuka bawang dan menemukan tidak ada lapisan lebih lanjut untuk didekripsi dan dapat membaca informasi pembayaran di dalamnya.
Silakan merujuk ke tautan Github di bawah ini untuk informasi lebih lanjut:
https://github.com/bpfkorea/agora/issues/1529
Lapisan Flash: Representasi dalam memori topologi jaringan #1583 (Pencarian Jalur, Fitur)
Ini dikerjakan oleh Omer. Ini adalah sub-masalah #1528. Masalah perutean pembayaran melalui jaringan kilat pada dasarnya adalah masalah grafik. Kita harus memiliki representasi jaringan dalam memori yang efisien yang disadari oleh Lightning Node. Sehingga kami dapat melintasi dan membangun jalur di sepanjang jaringan secara efisien.
Silakan merujuk ke tautan Github di bawah ini untuk informasi lebih lanjut:
https://github.com/bpfkorea/agora/issues/1583
Ubah kode klien dalam uji integrasi sistem untuk menggunakan Faucet #1553 (Pencarian Jalur, Fitur)
Ini dikerjakan oleh Chris. Sekarang kita memiliki aplikasi yang didedikasikan untuk membuat transaksi, kita dapat menggunakan ini sebagai cara untuk memberi makan jaringan uji integrasi, yang akan memberikan cakupan yang jauh lebih baik daripada kode klien saat ini dalam pengujian / sistem.
Silakan merujuk ke tautan Github di bawah ini untuk informasi lebih lanjut:
https://github.com/bpfkorea/agora/issues/1553
Memotong validasi informasi #1444 (Pencarian Jalur, Fitur)
Ini dikerjakan oleh Jay. Masalah ini terkait dengan #1076 yaitu tentang penerapan protokol pemotongan. Kami perlu membagi beberapa tugas yang terkait dengan validasi header blok dari masalah #1076 karena tugas memiliki banyak hal untuk dilakukan dan dapat memakan waktu.
Kami telah menambahkan informasi tentang validator yang dipotong menjadi satu blok. Informasi yang baru ditambahkan adalah sebagai berikut.
/// Hash benih acak dari preimages untuk ketinggian ini
Hash random_seed;
/// Daftar indeks ke set validator UTXO yang belum mengungkapkan preimage
uint [] validator_hilang;
Random_seed tidak boleh null dalam hal apa pun, yang dihasilkan dari preimages validator saat ini, dan harus sama dengan random_seed lokal dari node itu sendiri. Ini adalah hal-hal yang harus diperiksa rutin validasi. Pada kode Agora saat ini terdapat 2 kasus informasi tidak valid sebagai berikut disamping kasus dimana validator yang berperilaku tidak tepat memanipulasi informasi tersebut.
Dalam proses mengejar ketertinggalan, tidak ada gambar awal untuk menghasilkan benih acak lokal yang dibutuhkan untuk perbandingan. Jadi kita membutuhkan proses untuk mendapatkan pre-image dari node lain dan menambahkan informasi tersebut ke dalam ValidatorSet.
Dalam banyak pengujian unit atau pengujian jaringan, ada beberapa kasus yang tidak mempertimbangkan untuk mempertahankan preimages yang diperlukan untuk pemeriksaan validasi dan menghasilkan random_seed.
Sebagai tujuan dari masalah ini, kita harus menambahkan rutin validasi tentang pemotongan informasi dari header blok dan membuat kode melewati situasi dan tes di atas.
Silakan merujuk ke tautan Github di bawah ini untuk informasi lebih lanjut:
https://github.com/bpfkorea/agora/issues/1444
Flash: Buat paket bawang merah ukuran tetap #1614 (Saluran Pembayaran, Fitur)
Ini dikerjakan oleh Drey. Dalam #1529 paket terenkripsi bawang diimplementasikan. Namun, ukurannya bervariasi berdasarkan jumlah hop.
Di LN paket bawang selalu berukuran tetap. Ini memastikan tidak ada node yang dapat mengetahui berapa banyak lompatan yang telah dilalui paket atau berapa lompatan yang masih perlu dilalui. Lompatan hanya mengetahui lompatan sebelumnya dan lompatan berikutnya. Ini adalah fitur privasi penting.
Untuk ini kami membaca halaman-halaman ini:
https://github.com/lnbook/lnbook/blob/develop/03_how_ln_works.asciidoc
https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md
Silakan merujuk ke tautan Github di bawah ini untuk informasi lebih lanjut:
https://github.com/bpfkorea/agora/issues/1614
Menerapkan saluran pembayaran tidak langsung melalui HTLC #1419 (Saluran Pembayaran, Fitur)
Ini dikerjakan oleh Drey. Untuk membuat lapisan Flash nyaman digunakan dan lebih skalabel, kita perlu mengaktifkan perutean pembayaran melalui saluran tidak langsung.
Misalnya, pertimbangkan kasus dengan saluran berikut:
- Alice <=> Bob <=> Charlie <=> Dylan
Dalam tata letak saluran ini, Alice hanya dapat mengirim transaksi kilat ke Bob, dan dia tidak dapat mengirimnya ke Charlie atau Dylan. Alice perlu membuka saluran baru untuk Charlie dan Dylan.
Namun, ini merepotkan karena:
- itu meningkatkan jumlah transaksi on-chain
- itu meningkatkan jumlah pembukuan yang perlu dilakukan Alice
- itu menunda semua transaksi mikro sampai transaksi saluran terbuka dieksternalisasi
- itu menyebabkan biaya tambahan untuk semua pihak yang terlibat
Kita harus mendukung saluran pembayaran tidak langsung melalui penggunaan Kontrak Terkunci Waktu Hashed. Penjelasan singkat HTLC di saluran pembayaran disediakan di sini: https://hackernoon.com/what-are-hashed-timelock-contracts-htlcs-application-in-lightning-network-payment-channels-14437eeb9345
Mesin eksekusi kami sudah mendukung HTLC seperti yang ditunjukkan di sini serta timelock. Kami dapat menggunakannya di lapisan Flash kami untuk menerapkan saluran pembayaran tidak langsung.
Definisi selesai:
- Alice dapat mengirim transaksi mikro ke Dylan melalui saluran perantara
- Saluran flash tidak ditutup sampai semua HTLC diselesaikan
- Ada batasan untuk penundaan HTLC yang dapat diterima. Misalnya. Bob dapat memutuskan untuk menolak HTLC jika dia adalah perantara.
- Mengklaim HTLC harus otomatis
Silakan merujuk ke tautan Github di bawah ini untuk informasi lebih lanjut:
https://github.com/bpfkorea/agora/issues/1419
Node harus dapat pulih dari menghabiskan PreImageCycle #1500 mereka (Pembuatan Blok, Peningkatan)
Ini dikerjakan oleh Jay. Setelah semua preimage di PreImageCycle digunakan, node tidak dapat mendaftar lagi dengan UTXO yang sama.
Mereka harus dapat mentransfer koin mereka yang dipertaruhkan ke UTXO baru, membuat siklus gambar awal baru, dan mulai mendaftar dengannya.
Ini mungkin harus diaktifkan oleh konfigurasi recurring_enrollment atau yang baru.
Silakan merujuk ke tautan Github di bawah ini untuk informasi lebih lanjut:
https://github.com/bpfkorea/agora/issues/1500
Dalam transaksi pembekuan, output yang sesuai dengan pengembalian dana tidak akan dibekukan #1440 (Kegunaan, Bug)
Ini dikerjakan oleh Mathias. Saat ini, semua keluaran yang terdapat dalam transaksi pembekuan diperlakukan sebagai UTXO beku. Namun, UTOX yang setara dengan uang yang dikembalikan tidak boleh dibekukan dan harus digunakan kembali. Jika seseorang ingin membekukan hanya 40.000 BOA di UTXO dengan 50.000 BOA. Pengembalian dana yang setara dengan 10.000, hasil lain dari transaksi yang sama, tidak akan dibekukan.
Silakan merujuk ke tautan Github di bawah ini untuk informasi lebih lanjut:
https://github.com/bpfkorea/agora/issues/1440
Ongoing Validator Development:
- Merge the two key pair types into one #1645
- Flash: Monitor block height and trigger an update if HTLCs can be reclaimed #1619
- Validation-related routines should be moved out of Ledger #1550
- Define and implement block rewards #246
- Agora node does not catch up after restart #1512
- Agora eventually blocks, runs out of memory and dies under load #1480
- Flash layer: Implement path-finding algorithm #1528
- Add requirements for “Transition” page to wallet #93
- getRandomSeed() needs to assert instead of returning Hash.init #1663
- Listen to HTTP requests #27
- Hashing vulnerability with arrays #1331
- Flash layer: Determine fee rate algorithm #1527
- Gain background knowledge of Smart Contracts #1463
- Flash: Verify HTLCs with the encrypted packet parameters #1683
- Create submodule for Serializer #1684
- Eliminate unnecessary Enrollment requests during catch up. #1546
- Simplified Payment Verification (SPV) #239
- Unnecessary logs about slashing in the integration test should be removed #1613
- Switch address format from Stellar-style to bech32 #1655
- When running on the docker, no blocks above height 19 are created. #1552
- Integrate the Flash node and add system integration tests #1717
Pemasaran
T-Fi, Model Ekonomi Generasi Berikutnya yang menggabungkan Blockchain dan Ekonomi Tradisional
Kami bertujuan untuk “Membuat dunia yang lebih baik” melalui platform BOSAGORA. Sebagai langkah awal untuk mengimplementasikan dan mencapai visi tersebut, BOSAGORA meluncurkan proposal untuk ekosistem ekonomi T-Fi bulan lalu. T-Fi adalah singkatan dari True Finance, di mana merupakan model bisnis ekonomi generasi mendatang yang menggabungkan blockchain dengan ekonomi tradisional. Ini adalah model bisnis inovatif yang menggabungkan token BOA dengan layanan ekonomi untuk mengejar pengembalian yang stabil dan tinggi untuk semua orang.
T-Fi didasarkan pada nilai-nilai inti Transparansi, Keadilan, dan Publisitas. Silakan periksa tautan di bawah untuk informasi lebih lanjut.
Pedoman T-Fi: https://bit.ly/3v4pZdv
SATU HALAMAN
- KOREAN: https://bit.ly/38nDCuk
- ENGLISH: https://bit.ly/3bus4Yb
- CHINESE: https://bit.ly/3cj6JQU
YOUTUBE
- KOREAN: https://bit.ly/3vccFDK
- ENGLISH: https://bit.ly/38oNrbJ
BOSAGORA terintegrasi dengan Chainlink!
BOSAGORA telah berintegrasi dengan Chainlink, solusi oracle blockchain yang paling banyak diadopsi, untuk memastikan harga yang aman dan andal untuk menghitung pengembalian dalam model investasi staking pool inovatif kami. Kumpulan taruhan BOSAGORA BOA akan menggunakan Chainlink Price Oracle untuk menerbitkan pinjaman fiat yang didukung oleh token BOA, yang akan diinvestasikan ke FMway mitra BOSAGORA – algoritme investasi berbasis ekuitas.
Oracle Chainlink, yang dengan aman menghubungkan on-chain dan off-chain, tidak hanya bertindak sebagai jembatan antara kontrak trust on-chain dan API off-chain, oracle tidak hanya berfungsi sebagai jembatan antara kontrak trust on-chain dan API off-chain, tetapi memvalidasi integritas data dan menyediakan pengiriman yang aman ke blockchain untuk memastikan ketersediaan tinggi dan ketahanan terhadap gangguan. Ini akan semakin memperkuat integritas blockchain BOSAGORA.
Untuk informasi lebih lanjut, silakan cek tautan di bawah ini.
https://bit.ly/3rtTNOm
BOSAGORA Membuka Komunitas Turki
Setelah pembukaan komunitas Rusia dan Spanyol pada bulan Januari, BOSAGORA telah menyadari bahwa permintaan di lebih banyak wilayah dan secara bertahap memperluas komunitas khusus bahasa. Oleh karena itu, komunitas Turki baru-baru ini dibuka dan sejak itu, banyak pemegang bahasa tersebut telah berpartisipasi dan berkembang pesat.
Di masa mendatang, kami akan terus membuka komunitas individu dalam berbagai bahasa dan membagikan informasi terperinci yang diperlukan untuk memastikan tidak ada yang melewatkannya, sehingga kami dapat terus berkembang dengan semua pemegang global.
Telegram Turki: https://t.me/BosagoraTR
Rekap Kucoin AMA
Setelah pengumuman bersejarah T-FI pada bulan Februari, kami telah menerima undangan AMA dari banyak komunitas dan pertukaran, dan kami telah melakukan AMA dengan KuCoin, yang baru-baru ini terdaftar. Pada AMA ini, berhasil mengidentifikasi semua pemegang yang tertarik dengan T-Fi dengan menjawab pertanyaan mendalam terkait T-Fi, seperti pedoman T-Fi, peminjaman, dan struktur pendapatan.
Kedepannya, kami akan terus merespon tentang kemitraan baru dengan pencapaian perkembangan, dan berkomunikasi secara aktif melalui AMA yang sedang berlangsung.
Tren Teknologi
Tren Teknologi adalah kolom BOSAGORA yang melihat teknologi dan tren industri blockchain. Tren Teknologi akan menyampaikan pengetahuan dan pandangan mendalam tentang teknologi dan kebijakan baru, yang akan menentukan arah industri serta tren blockchain dan mata uang kripto yang menarik perhatian tahun ini di tahun 2021. Silakan periksa tautan untuk informasi lebih lanjut.
Kolom Tren Teknologi 1 Februari
Bisakah CBDC Memberikan Legitimasi kepada Industri Crypto?
Inggris: https://bit.ly/3qxr61M
Kolom Tren Teknologi 2 Februari
Bagaimana BOSAGORA Akan Terbukti di Masa Depan Dengan VOTERA
Inggris: https://bit.ly/38qlj7Z
