Kerangka kerja: analisis sistem DLT

Karya ini bertujuan untuk menentukan apakah objek yang dianalisis adalah sistem DLT. Hasil yang diperoleh sangat cocok untuk analisis komparatif dari berbagai proyek, mulai dari struktur manajemen hingga definisi tautan yang merujuk transaksi.

Teknologi buku besar terdistribusi adalah teknologi penyimpanan informasi yang fitur utamanya adalah berbagi dan sinkronisasi data digital sesuai dengan algoritma konsensus, distribusi geografis dari salinan yang setara di berbagai titik di seluruh dunia, tidak adanya administrator pusat.

Analisis teknis

Tingkat protokol

Kejadian

Level protokol, mengacu pada proses yang perlu dikembangkan dan dijalankan sebelum jaringan dimulai.

Ketergantungan pada jaringan lain.

Ketergantungan pada protokol lain tergantung pada batas-batas proyek yang dianalisis. Ini menentukan apakah sistem dapat beroperasi sebagai sistem independen (mandiri) atau tergantung pada jaringan lain.

Tabel 1. Ketergantungan pada sistem lain



Kode program

Kode dapat didasarkan pada kerangka kerja yang ada atau ditulis dari awal. Kerangka kerja yang paling populer adalah basis kode dari sistem open source (Bitcoin / Ethereum). Ada juga database sumber tertutup untuk platform tertutup yang disediakan oleh proyek-proyek seperti Aset Digital / Clearmatics dan SETL.

Tabel 2. Kode Program



Mendefinisikan Aturan

Pengenalan aturan mengacu pada definisi seperangkat aturan di mana sistem DLT harus beroperasi. Proses ini dapat dilakukan oleh peserta yang berbeda dan bersifat individual untuk sistem DLT tertentu.

Pembaruan protokol

Pembaruan protokol berlaku untuk proses yang ada yang memungkinkan Anda untuk mengubah aturan sistem. Memperbarui protokol dapat mencakup penghapusan kesalahan teknis (bug), meningkatkan keamanan dan fungsionalitas sistem, serta memperluas atau membatasi aturan protokol yang ada.

Manajemen protokol

Manajemen protokol mengacu pada serangkaian proses pengambilan keputusan yang memungkinkan Anda untuk mengubah protokol secara teratur dan legal. Ini adalah bagian dari manajemen proyek yang lebih luas, yang mencakup serangkaian proses dan norma lengkap yang menggambarkan dan menentukan koordinasi dan tindakan, tetapi yang tidak dapat secara formal diintegrasikan ke dalam sistem DLT.

Unsur penting dari setiap perubahan yang diusulkan pada protokol adalah cara protokol itu diadopsi dan diratifikasi - atau, dengan kata lain, bagaimana legitimasi diberikan atas saran peserta jaringan. Karena legitimasi dalam konteks ini adalah konsep sosial, tampaknya masuk akal untuk mengidentifikasi beberapa kemungkinan hubungan "sosial-politik" yang ditemukan dalam sistem DLT.

Tabel 3. Manajemen Protokol



Manajemen protokol memiliki banyak bentuk dan seringkali tidak jelas. Awalnya, sistem DLT ditandai oleh kekuatan anarkis (gratis), tidak ada perusahaan atau kelompok orang yang bertanggung jawab untuk membuat keputusan. Sebagian besar, mereka mirip dengan proses manajemen lalu lintas open-source. Contoh diskusi tentang perubahan protokol, dapat berupa komunikasi pengembang dalam obrolan / GitHub / konferensi. Di bawah kondisi diktator, proses membahas perubahan mungkin persis sama, tetapi keputusan akhir akan dibuat oleh satu orang. Dalam beberapa kasus, bentuk manajemen protokol dapat didefinisikan oleh lebih dari satu jenis papan. Misalnya, blockchain EOS bertindak sebagai federasi produsen blok yang dipilih oleh pengguna yang memiliki aset EOS. Berat suara ditentukan oleh jumlah token yang ada pada alamat. Jenis pemerintahan ini membagi protokol menjadi dua pihak: pengguna "elit" dan "biasa", mengambil karakteristik sistem hierarkis: federasi, demokrasi dan plutokrasi.

Manajemen on-chain, menyiratkan dimasukkannya fungsi manajemen di tingkat data. Tujuannya adalah untuk memformalkan tata kelola, sehingga meningkatkan legitimasi dan menghindari fragmentasi jaringan karena perselisihan atau pembaruan protokol yang tidak konsisten. Serangkaian skema pemungutan suara on-chain yang beragam telah dikembangkan untuk sistem DLT, mulai dari barometer suasana hati masyarakat hingga referensi. Namun, fungsi manajemen on-chain, sebagai suatu peraturan, hanya merupakan tambahan untuk bentuk manajemen lainnya.

Perubahan Protokol

Proses aktual memperbarui protokol menyiratkan:

1. memperbarui kode pada GitHub jika itu adalah proyek open-source;
2. pembaruan klien jika itu adalah protokol sumber tertutup;
3. Klien yang mengerjakan kode program lama dapat dianggap tidak relevan dan masuk daftar hitam;
4. Klien yang berjalan pada kode program lama membentuk garpu, yang mengarah pada pembuatan versi alternatif protokol.

Tabel 4. Bentuk modifikasi protokol



Sistem DLT yang berbeda menggunakan metode yang berbeda untuk memperbarui jaringan. Misalnya, Ethereum menerima donasi untuk membiayai pengembangan, dan juga memperbarui jaringan menggunakan perangkat lunak dari pengembang yang didanai oleh hibah.

Tingkat jaringan

Jaringan protokol DLT adalah hasil langsung dari penerapan aturan protokol. Jaringan ini terdiri dari kerja para peserta yang terkoordinasi dan proses-proses yang mematuhi standar teknologi (protokol) dan secara aktif terlibat dalam pertukaran data dan informasi melalui saluran komunikasi tertentu.

Proses komunikasi

Proses mentransfer data antara peserta dalam sistem DLT.

Akses jaringan

Akses ke jaringan menyiratkan kemungkinan menghubungkan ke protokol, bisa terbatas atau tidak terbatas.

• Akses tidak terbatas - setiap pengguna dapat dengan bebas terhubung / memutuskan kapan saja;
• Akses terbatas - hanya pengguna tertentu yang dapat terhubung ke jaringan, biasanya ini dikendalikan oleh entitas yang ditunjuk.

Sebagai aturan, sistem dengan akses tak terbatas tidak memiliki batasan pada jumlah peserta, sementara jaringan tertutup dapat menetapkan jumlah peserta terbatas.

Biasanya, peserta mendapatkan akses langsung ke jaringan dengan meluncurkan node penuh: mereka dianggap sebagai "elit" dengan seperangkat hak besar, karena mereka dapat mengirim / memverifikasi dan mentransfer data catatan. Peserta jaringan juga bisa mendapatkan akses tidak langsung ke jaringan dengan menjalankan "klien cahaya" yang meminta data dari node lengkap dengan menghubungkan melalui layanan khusus (API).

Tabel 5. Formulir Akses Jaringan



Sebagai aturan, semakin terbuka sistem, semakin rentan terhadap serangan. Secara khusus, sistem ini rentan terhadap serangan Sibyl, ketika penyerang menciptakan banyak identitas palsu untuk meningkatkan pengaruh pada jaringan.

Serangan Sibyl adalah jenis serangan ketika penyerang mendapatkan akses atau menyembunyikan perubahan dalam protokol, menciptakan banyak identitas palsu.

Karena identifikasi adalah properti eksogen (yaitu, "nyata"), sistem DLT tidak dapat mencegah serangan ini, itu harus bergantung pada peserta eksternal (sistem sertifikasi) atau mekanisme yang mengurangi kemungkinan serangan (PoW / PoS).

Mengirim data

Transfer data adalah proses mendistribusikan data ke node yang terhubung. Data dapat mentah / tidak diformat atau distandarisasi ke format tertentu (misalnya, dalam bentuk transaksi atau catatan). Data dapat ditransmisikan ke setiap node (difusi universal), atau hanya ke subset node tertentu (difusi multichannel). Dalam kasus terakhir, distribusi data biasanya terbatas pada peserta dalam transaksi. Ini memungkinkan Anda untuk membuat "saluran" untuk transfer data, biasanya dengan ini dimaksudkan jaringan sharding / Lightning.

Sistem DLT awal (mis. Bitcoin, Litecoin) menggunakan model distribusi data universal, yang tetap menjadi metode distribusi data paling populer.

Untuk menjaga anonimitas dan privasi bagi perusahaan, sistem selanjutnya memiliki model difusi multi-saluran (mis., Hyperledger Fabric, Corda). Sistem lain, seperti Cosmos, dirancang untuk bertindak sebagai hub sehingga sistem DLT independen dapat saling terhubung melalui sharding.

Tabel 6. Formulir Pengiriman Data



Contoh difusi data multi-saluran adalah bahwa tidak semua peserta jaringan harus berpartisipasi dalam konsensus tentang status saluran: hanya peserta saluran yang harus mencapai konsistensi atas data yang disimpan dalam saluran ini (konsensus "lokal"). Ini sangat berbeda dari sistem dengan difusi data global, karena setiap node individu harus mencapai konsensus tentang keadaan global sistem (konsensus "global"); ketidakmampuan untuk mencapai konsensus dari beberapa node dapat menyebabkan terputusnya mereka, atau pembuatan garpu.

Penciptaan Transaksi

Proses pembuatan transaksi berisi serangkaian instruksi yang akan dieksekusi setelah transaksi ditambahkan ke jaringan. Membuat transaksi dapat tidak terbatas (mis. Dapat diakses oleh semua) atau terbatas pada beberapa peserta. Transaksi dibuat oleh pengguna yang menandatangani pesan dengan kunci pribadi mereka. Berbagai antarmuka tersedia bagi pengguna untuk membuat dan mengirim transaksi ke jaringan (misalnya, PC dan dompet seluler).

Pemrosesan transaksi

Pemrosesan transaksi menjelaskan serangkaian tindakan yang diperlukan untuk menambahkan transaksi yang belum dikonfirmasi ke daftar yang dikonfirmasi. Suatu transaksi dianggap (pendahuluan) valid setelah menambahkan ("dikonfirmasi") ke dalam daftar, yang mengarah pada pelaksanaan instruksi yang tertanam dalam transaksi. Namun, konfirmasi saja tidak cukup untuk transaksi ini menjadi dasar untuk operasi selanjutnya; sebelum output transaksi dapat digunakan oleh sistem.

Gambar 1. Pemrosesan transaksi dalam sistem DLT



Rekaman mematuhi algoritma konsensus spesifik yang digunakan dalam sistem DLT. Ini termasuk proses menentukan apakah catatan yang diajukan valid, serta menolak entri yang tidak valid (misalnya, entri yang rusak atau tidak kompatibel) dan memilih antara entri yang berbeda tetapi sama-sama valid.

Catat Kandidat

Entri yang dapat dipindahkan ke daftar transaksi yang dikonfirmasi di masa mendatang dikirim oleh pencipta blok, yang memilihnya dari daftar transaksi yang belum dikonfirmasi dan menggabungkannya bersama-sama untuk membentuk kandidat untuk menulis ke daftar catatan yang dikonfirmasi. Ada dua properti yang menentukan hak untuk mengirim catatan dan penyertaannya di masa depan dalam daftar catatan yang dikonfirmasi.

Tabel 7. Formulir Rekam



Karena catatan tunduk pada konsensus, mereka harus mematuhi aturan protokol. Pertama, mereka harus diformat dengan benar dan tidak mengandung transaksi yang tidak valid atau tidak valid. Selain itu, setiap entri harus menyertakan tautan / penunjuk ke entri sebelumnya dan, jika perlu, gunakan PoW atau metode lain apa pun yang menyulitkan untuk melakukan serangan Sibyl.

Algoritma konsensus dapat diklasifikasikan berdasarkan tingkat kerumitannya (biaya listrik / moneter). Algoritma dengan kompleksitas tak terbatas diukur dalam sumber daya yang diperlukan untuk mencapai konsensus. Misalnya, dalam hal menghitung PoW Bitcoin, kesulitan menemukan solusi yang tepat meningkat seiring dengan kompleksitas hashing data. Justru sebaliknya, algoritma lain bekerja (misalnya, tugas-tugas Jenderal Bizantium / BFT) tidak memerlukan biaya komputasi yang signifikan dan memiliki kompleksitas yang terbatas.

Dalam sistem terbuka, algoritma harus disediakan yang mengurangi kemungkinan serangan Sybil. Sistem pribadi (tertutup) memeriksa setiap peserta sebelum memungkinkan mereka mengakses koneksi jaringan, yang mencegah kemungkinan serangan. Dalam sistem tertutup, sekelompok node cenderung memilih satu node yang akan membuat blok.

Resolusi Konflik

Konflik dapat disebabkan karena beberapa alasan:

1. peserta tidak setuju pada versi protokol mana yang relevan;
2. peserta tidak setuju tentang transaksi yang diverifikasi.

Jika terjadi situasi titik pertama dalam jaringan Bitcoin, jaringan memilih rantai blok terpanjang yang valid, dan mengabaikan yang lebih pendek. Dalam Tezos, validitas suatu blok ditentukan dengan “berat blok” yang berbeda, bobot di sini adalah jumlah “persetujuan” dari validator yang diterima secara acak dari pembuat.

Algoritma konsensus apa pun membawa sejumlah pengorbanan

Tabel 7. Bentuk motivasi untuk pemrosesan transaksi



Validasi

Validasi mengacu pada serangkaian proses yang diperlukan untuk memastikan bahwa subjek secara independen sampai pada kesimpulan yang sama mengenai serangkaian catatan yang disetujui. Ini termasuk: memeriksa transaksi terkirim / memeriksa data yang direkam / memeriksa status umum jaringan. Ini adalah perbedaan penting dari sistem non-DLT, karena memberikan peserta dengan kesempatan untuk melakukan audit independen terhadap sistem.

Verifikasi Transaksi

Memverifikasi transaksi adalah untuk memastikan bahwa catatan individu mematuhi aturan protokol sebelum mentransfernya ke entitas lain. Ini termasuk: kebenaran format transaksi, adanya tanda tangan yang sesuai dan pemenuhan syarat bahwa transaksi tidak bertentangan dengan yang lain. Beberapa sistem dapat mengoperasikan sistem yang melarang transaksi hingga titik waktu tertentu atau alasan lain. Biasanya, kondisi seperti itu dipenuhi oleh kontrak pintar.

Serangan 51% adalah kasus ketika seorang peserta atau beberapa peserta menggabungkan kekuatan komputasi mereka (suara) dan memproses transaksi pada jaringan lebih cepat daripada protokol lainnya. Serangan semacam itu memungkinkan Anda untuk melakukan transaksi yang tidak valid dan mencatatnya sebagai sah. Terutama yang rentan adalah sistem menggunakan PoW

Periksa Catatan

Memeriksa catatan yang dikirim memungkinkan Anda untuk memastikan bahwa catatan tersebut mematuhi aturan protokol. Jika entri yang diajukan diakui sebagai valid, itu ditambahkan ke daftar entri yang dikonfirmasi dan disampaikan ke semua node yang terhubung dalam jaringan. Meskipun proses ini berbeda di setiap sistem, tetapi, pada prinsipnya, berdasarkan prinsip-prinsip umum, serupa di mana-mana, misalnya, memeriksa bahwa pekerjaan PoW telah dilakukan pada transaksi. Kombinasi verifikasi transaksi yang dikirim dan pencatatan selanjutnya oleh validator memberikan audit independen terhadap keseluruhan sistem.

Catatan transaksi

Transaksi / catatan yang dikonfirmasi tidak harus dapat dikembalikan. Write irreversibility dapat bersifat probabilistik (misalnya, sistem berbasis PoW yang tidak praktis untuk menghitung ulang semua transaksi yang tercatat), atau sistem yang mencakup "pos pemeriksaan" yang harus ditetapkan untuk setiap transaksi. Catatan yang dikonfirmasi dapat disebut tidak dapat diubah, tetapi catatan yang telah "dikonfirmasi sebelumnya" dapat dibatalkan. Catatan pra-dikonfirmasi menjadi tidak berubah setelah mengatasi keadaan transisi dari "pra-dikonfirmasi" ke "dikonfirmasi".

Gambar 2. Pemrosesan transaksi dalam sistem DLT



Gambar 2 menggambarkan deskripsi skematis dari proses yang terjadi selama pemrosesan transaksi. Pertama, pengguna membuat transaksi dan mengirimkannya ke jaringan. Setiap node memeriksa untuk melihat apakah transaksi sesuai dengan aturan protokol. Jika dianggap benar, simpul menambahkan transaksi ke daftar (mempool), di mana semua transaksi yang belum dikonfirmasi disimpan, menunggu untuk ditambahkan ke daftar transaksi yang dikonfirmasi.

Pada tahap pemrosesan transaksi, node secara acak memilih transaksi yang belum dikonfirmasi dari mempool mereka dan kemudian menggabungkannya menjadi daftar transaksi "yang disetujui sebelumnya". Selanjutnya, transaksi akan diperiksa sesuai dengan algoritma konsensus untuk menawarkan transaksi ini kepada semua peserta jaringan lainnya. Node akan melihat transaksi yang diterima dan isinya, jika transaksi lolos verifikasi, transaksi ditambahkan ke daftar node. Daftar dengan transaksi dari masing-masing node akhirnya dikirim ke daftar tunggal, transaksi yang paling penting dari transaksi yang dikonfirmasi dan akan dianggap selesai.

Namun, transaksi yang dikonfirmasi dapat "dibatalkan" karena transaksi alternatif, yang berarti bahwa pada tahap penyelesaian, transaksi dapat dibatalkan - dalam hal ini mereka kembali ke simpul sebagai transaksi yang belum dikonfirmasi, menunggu untuk membuat daftar transaksi baru. Waktu pemrosesan transaksi pada tahap "Penyelesaian" tergantung pada pengaturan sistem tunggal. Beberapa sistem menerapkan pencatatan instan transaksi dan tidak dapat dibatalkannya kembali, tetapi, beberapa protokol memiliki penyelesaian "probabilistik", dalam arti bahwa transaksi secara teoritis dapat dibatalkan. Namun dalam praktiknya, kemungkinan tindakan ini berkurang dengan setiap transaksi baru ditambahkan, karena biaya simpul yang terkait dengan PoW dapat menjadi tinggi. Sementara transaksi berada pada tahap "penyelesaian", mereka tidak dapat dianggap "selesai". , , , .

« », «long-range». , ( ), , «», . « » — , . , «» . , .

8.

, . . , , .



, .



. , , , (, , ) -.

, - . , , , , (. ). , « – state channel» , .

9.



-

. - . -. , , , , . DLT-, (). , Bitcoin Script, , - . – Stateless. Ethereum (Solidity), Tezos (Michelson) EOS (WebAssembly) – -, Bitcoin Monero, , .

10. -





, , . , – on-chain off-chain ( ). On-chain . , , (EVM – Ethereum), . - on-chain , « ».

Off-chain , , . , , on-chain, , . , (Hybrid) , , Plasma Ethereum. , , Cosmos, «», .

11. -

Referensi

, DLT-, . , – . , DLT-, . , , , , . , DLT-, -, , . , – .



: , , .

() , , , «» . , Bitcoin, , . , . () , , , . , , . , , : – . , - – , . - , - (« »).

12.

Kesimpulan

, DLT-. , , , , .