Apa itu Dragonchain, DRGN Coin adalah

Apa itu Dragonchain, DRGN Coin ?

Dragonchain adalah platform blockchain hybridnya sendiri untuk bisnis kecil, perusahaan, dan pengembang. Awalnya dikembangkan di dalam The Walt Disney Company di Seattle pada tahun 2014 oleh Joe Roets, dan kemudian bersumber terbuka pada tahun 2016.

Dragonchain, DRGN Coin

Platform blockchain hybrid publik/swasta juga memungkinkan integrasi dengan blockchain eksternal dan sistem warisan melalui Interchain™, mengintegrasikan oracle pihak ketiga, API, IoT, rantai pasokan, dan data bisnis lainnya. Dragonchain membuktikan interoperabilitasnya pada tahun 2016 dan saat ini menggunakan Interchain™ untuk terhubung ke Bitcoin, Ethereum, Binance Chain, dan Ethereum Classic. Bermigrasi dengan mudah dari off-chain, ke on-chain, sambil tetap mampu GDPR. Pengembang dapat menulis kontrak pintar mereka sendiri dalam bahasa pengkodean apa pun, seperti C++, Go, JavaScript, Java, Python, Ruby, Shell, C#, Hy, Rails, PHP, dan lainnya yang memungkinkan mereka membangun aplikasi blockchain (terdesentralisasi) di tempat atau di lingkungan multi-cloud.

Kemampuan penting termasuk enkripsi dan penandatanganan kuantum, sistem perilaku, forum sosial dan pasar tata kelola, analitik prediktif dan ilmu kompleksitas untuk manajemen rantai pasokan, serta pelacakan dan akuntansi lingkungan.

Pada 7 Januari 2020, Dragonchain mendemonstrasikan lebih dari 250 juta transaksi selama acara streaming langsung 24 jam, dengan rata-rata lebih dari 1500 transaksi per detik. Belakangan tahun itu Medek Health meluncurkan Covid SafePass dengan Kota Apopka, menggunakan solusi blockchain Dragonchain sesuai dengan panduan FDA tentang Kebijakan Kesehatan Digital dan Solusi Kesehatan Masyarakat untuk COVID-19.

Dragonchain juga membangun beberapa solusi internal di atas platform open source, termasuk Dragon Factor (identitas terdesentralisasi), Den (media sosial terdesentralisasi), Sistem Kontes yang Terbukti Adil (kontes, kasino, lotere, hadiah), Lyceum (Pelatihan kursus & sertifikat pada rantai), dan Abadi (pengarsipan, bukti hukum, prediksi).

Bagaimana cara menambang Dragonchain ?

Tidak ada penambangan yang terlibat. Komunitas bertindak sebagai desentralisasi validasi, keragaman, dan layanan notaris. Salah satu paten yang diberikan kepada Dragonchain berkisar pada loyalitas & penghargaan di blockchain.

Sementara perusahaan mengembangkan aplikasi mereka pada node Bisnis Level 1 pribadi, komunitas Dragonchain dan mitra terpilih menjalankan node Validasi Level 2, Keragaman Level 3, dan Notaris Level 4 mereka sendiri. Node level 5 adalah pos pemeriksaan publik ke blockchain eksternal seperti Bitcoin, Ethereum, dan Binance Chain. Node level 5 dapat dijalankan dan dikelola oleh Dragonchain, atau blockchain spesifik itu sendiri melalui program mitra, membawa interoperabilitas ke semua blockchain.

Untuk anggota komunitas Dragonchain yang menjalankan node, jumlah TIME yang diterapkan setiap pelari node ke level tertentu, menentukan hadiah mereka.TIME adalah skor loyalitas di atas token DRGN. Untuk setiap DRGN yang disimpan di dompet non-pertukaran, mereka menerima skor loyalitas 1 TIME per hari secara otomatis.

Semakin banyak TIME yang diterapkan seseorang ke node L2, L3, atau L4, semakin tinggi hadiah yang diberikan ketika node Anda dipilih melalui proses matchmaking. Anggota komunitas yang mengamankan 5 tingkat kepercayaan Dragon Net dapat bergabung dengan node yang dikumpulkan, atau menjalankan node mereka sendiri yang tidak dikelola.

ARSITEKTUR RANTAI NAGA Dragonchain

Tujuan Dragonchain adalah untuk menguraikan dan mengomunikasikan arsitektur dan desain platform blockchain yang akan memungkinkan kemudahan integrasi untuk aplikasi bisnis nyata. Menurut pendapat penulis, ada kebutuhan yang berkembang untuk integrasi blockchain yang disederhanakan. Pendekatan terdesentralisasi dan tunggal untuk implementasi blockchain terkadang bertentangan dengan kebutuhan bisnis nyata untuk melindungi informasi dan mengontrol proses bisnis. Dokumen ini berusaha menjelaskan dan memberikan contoh untuk keberhasilan implementasi elemen arsitektur blockchain yang disebutkan.

TUJUAN ARSITEKTUR

1. Kemudahan integrasi sistem yang ada
2. Kemudahan pengembangan untuk insinyur dan pembuat kode tradisional yang tidak terbiasa dengan blockchain, sistem terdistribusi, dan kriptografi
3. Gaya server klien dan titik integrasi RESTful sederhana untuk integrasi bisnis
4. Arsitektur sederhana (fleksibel dan dapat digunakan untuk aplikasi yang tidak terduga)
5. Memberikan perlindungan data bisnis secara default
6. Izinkan kontrol proses yang berfokus pada bisnis
7. Blok periode panjang tetap
8. Blok pendek/cepat
9. Blockchain agnostik mata uang (dukungan multi-mata uang)
10. Tidak ada mata uang dasar
11. Interoperabilitas dengan blockchain lain, publik dan pribadi
12. Adopsi standar saat tersedia, lihat standarisasi blockchain W3C Blockchain Community Group (https://github.com/w3c/blockchain/blob/master/standards.md) dan Catatan Standarisasi Blockchain Disney (https://dragonchain.github .io/blockchain- standarisasi)
    ELEMEN ARSITEKTUR

ABSTRAKSI BUKTI Dragonchain

Di Bitcoin dan sebagian besar cryptocurrency lainnya, kami menyaksikan penggunaan algoritme “Proof of Work” (PoW) sebagai dasar untuk konsensus dalam sistem “tanpa kepercayaan”. Dalam arsitektur ini, “bukti” akan diabstraksikan dan dapat diimplementasikan dalam satu atau lebih cara untuk blockchain tertentu. Untuk beberapa penggunaan, seseorang mungkin ingin menggunakan sistem berbasis kepercayaan, misalnya, dalam sistem blockchain yang sepenuhnya pribadi. Seseorang juga dapat menemukan nilai dalam konfigurasi bukti hibrida yang akan melihat kepercayaan diterapkan bersama Bukti Kerja terbatas untuk menambahkan keamanan tambahan terhadap serangan (yaitu penyerang potensial tidak hanya perlu berkompromi atau mendapatkan satu set kunci pribadi, tetapi juga perlu melakukan perhitungan untuk menyelesaikan Bukti yang dikonfigurasi untuk memasang kembali blockchain yang diberikan.

Implementasi Bukti:

1. Kepercayaan (Default)
2. Bukti Kerja (PoW)
3. Bukti Taruhan (PoS)
4. Algoritma lain yang belum ditentukan

Dengan abstraksi seperti itu, pengguna akan dapat mengonfigurasi satu atau lebih bukti simultan untuk memenuhi kebutuhan bisnis, sementara pengembang sistem dapat membangun implementasi bukti baru seiring kemajuan teknologi blockchain.

Dimungkinkan untuk melakukan PoW bahkan dalam kasus konstruksi blok dengan panjang waktu tetap (lihat diskusi konstruksi blok di tempat lain dalam makalah ini) dengan merentangkan satu atau lebih implementasi bukti di seluruh blok.

Sebagai contoh, katakanlah kita memiliki kasus penggunaan tertentu yang membutuhkan keamanan lebih tinggi dari biasanya. Jika kami berasumsi bahwa Trust diimplementasikan secara default, tetapi kami ingin mengonfigurasi sejumlah verifikasi tanpa kepercayaan, kami mungkin ingin mengonfigurasi beberapa tingkat Proof of Work di blockchain kami. Tergantung pada tingkat kesulitan yang dikonfigurasi, dan mengingat sifat algoritma PoW, kita mungkin tidak melihat solusi PoW untuk setiap blok. Beberapa blok tidak memiliki PoW, dan jawaban PoW mungkin hanya muncul sesekali.

Dalam kasus seperti itu, mungkin masuk akal untuk mengonfigurasi dua atau lebih level PoW. Bukti kesulitan yang lebih tinggi dapat disetel untuk muncul kira-kira setiap 20 menit, dan bukti kesulitan yang lebih rendah dapat disetel untuk muncul kira-kira setiap 2 detik.

Dengan cara yang sama, bukti lain seperti PoS dapat diterapkan secara bersamaan dalam satu rantai. Poin filosofis yang menarik adalah bahwa bukti tersebut dapat digunakan dalam persaingan melawan penyerang masa depan daripada sebagai persaingan dengan penambang lain untuk mendapatkan hadiah blok.

CHECKPOINTING DAN BUKTI KEBERADAAN

Elemen lain dalam abstraksi bukti adalah kemampuan lebih lanjut untuk berhibridisasi dengan melakukan checkpoint ke blockchain (publik) lainnya. Ini dapat dilihat sebagai tingkat pertama atau interoperabilitas sederhana antara blockchain, publik atau pribadi.

Nilai potensial tertentu, adalah kemampuan untuk memastikan risiko dengan mengukur atribut blockchain publik. Artinya, jika dikaitkan dengan blockchain publik yang menggunakan PoW seperti Bitcoin, sistem dapat memperkirakan jumlah hashpower yang telah diterapkan sejak pos pemeriksaan dan bahkan mengekstrapolasi daya komputasi tersebut ke dolar yang dihabiskan.

Dengan ini, unit risiko dapat dikembangkan yang menunjukkan berapa banyak daya komputasi yang dibutuhkan (dan berapa biayanya) untuk menghitung persentase kemungkinan keberhasilan dalam upaya memalsukan artefak tertentu (misalnya, transaksi bernilai tinggi). Dengan cara yang sama, mengikat pos pemeriksaan ke blockchain publik berdasarkan PoS, sistem dapat mengukur jumlah aset yang harus dimiliki (dan kemungkinan dikorbankan) untuk memalsukan transaksi yang bersangkutan.
Lihat pembahasan verifikasi Level 5 di bawah ini untuk informasi lebih lanjut.

DEFINISI TRANSAKSI

Transaksi adalah dasar di mana semua peristiwa atau transfer data dicatat dalam platform blockchain. Sistem harus mendefinisikan struktur transaksi standar yang fleksibel dan dapat diperluas.

Opsi implementasi:

JSON dengan struktur standar JWT (JSON Web Token)
Struktur terenkode lainnya (dengan pustaka pendukung dalam berbagai bahasa)

KEPALA

Berisi bidang metadata standar standar yang ditentukan sistem atau jaringan untuk transaksi.

Contoh bidang:

ID Transaksi Jenis transaksi Kelas transaksi Buat stempel waktu Stempel waktu transaksi ID Asal
Organisasi bisnis dan/atau taksonomi organisasi Pelaku
Kesatuan

PAYLOAD

Struktur dan konten sewenang-wenang, ditentukan pada tingkat bisnis dan diimplementasikan atau dikendalikan dalam kode persetujuan tingkat 1.

Beberapa tingkat struktur dalam payload (misalnya bidang dan struktur) dapat diimplementasikan sebagai templat di seluruh jaringan untuk digunakan dan dicatat berdasarkan bidang header kelas transaksi opsional. Ini akan memungkinkan node untuk menerapkan beberapa perilaku yang diperlukan yang ditentukan di tingkat Perusahaan atau jaringan, serta penyederhanaan kemampuan seperti mata uang. Lihat di bawah untuk contoh kelas transaksi.

TANDA TANGAN

Bagian dari transaksi yang memegang tanda tangan kriptografi untuk memungkinkan para pihak membuktikan sumber dan/atau bahwa isi transaksi tidak berubah sejak penandatanganan (yaitu bukti rusak). Tanda tangan dalam transaksi tidak boleh diminta dari sumber transaksi (misalnya klien atau sistem pihak ketiga) karena beberapa klien mungkin tidak diaktifkan secara kriptografis atau mengetahui platform blockchain. Sebagai alternatif, sistem klien misalnya dapat meminta proses penandatanganan multi-pihak sebelum pengiriman transaksi. Either way, komponen Layanan Transaksi node platform blockchain harus secara kriptografis menandatangani setiap transaksi masuk yang diterimanya untuk diproses (dengan pasangan kunci yang dikonfigurasi).

Persyaratan yang dirasakan:

Strukturnya harus memungkinkan penandatanganan multi-partai dan bersarang
Tanda tangan harus meng-hash semua bidang dalam struktur tanda tangan itu sendiri dikurangi hash dan tanda tangan untuk membuat tanda tangan itu sendiri terbukti rusak
Struktur harus melihat penggunaan kembali dalam proses penandatanganan catatan verifikasi (verifikasi blok)

Bidang:

Penandatangan Hash
Stripped Hash (hanya untuk tanda tangan transaksi – hash dari transaksi penuh dengan payload dilucuti – untuk memungkinkan node level 2+ memvalidasi transaksi bahkan ketika payload tidak tersedia)
Stempel Waktu Penandatanganan Kunci Publik
Tanda tangan
Tanda Tangan Anak (opsional)

Opsi implementasi:

JWS (Tanda Tangan Web JSON) JSON Khusus

KELAS

Beberapa contoh kelas transaksi yang mungkin adalah:

• Default (struktur payload bisnis Level 1 kustom)
• Penyediaan Mata Uang
• Komunikasi jaringan
• Transaksi pasar
• Interoperabilitas informasi (mata uang blockchain asing atau muatan informasi)

DEFINISI BLOK

Definisi blok dapat melihat beberapa implementasi, meskipun ada lebih banyak atau lebih sedikit elemen umum yang terlibat seperti:

• Blokir Transaksi Stempel Waktu ID
• Tanda tangan artefak Bukti blok sebelumnya (misalnya PoW, PoS)
• Atribut verifikasi periode blok

Bagian menarik dari desain definisi blok yang sering tidak diperhatikan adalah pertanyaan kapan blok itu terbentuk. Dalam Bitcoin atau sistem PoW lainnya, blok terbentuk ketika algoritma PoW diselesaikan untuk kesulitan jaringan saat ini. Ini mungkin terjadi setelah 30 detik atau 30 menit. Ini bervariasi dan acak, tetapi jaringan berusaha untuk menyesuaikan kesulitan untuk menyesuaikan waktu blok rata-rata menjadi 10 menit.

Dalam sistem berbasis kepercayaan, tidak akan ada kebutuhan mutlak untuk mempertahankan blok berbasis waktu variabel. Di banyak sistem dunia nyata, sebenarnya dilihat sebagai kerugian penggunaannya bahwa Bitcoin tidak dapat menawarkan waktu blok rata-rata yang tetap atau lebih cepat. Dalam arsitektur ini, kita mungkin menginginkan waktu blok yang lebih tepat, seperti waktu tetap dalam detik (misalnya 5 detik). Definisi waktu blok yang cepat dan tetap seperti itu mengarah pada pertanyaan konsensus, yaitu, bagaimana seluruh jaringan mencapai konsensus setiap 5 detik? Dengan konteks

verifikasi berbasis dan konsep “blockchain of blockchains” (dibahas di bawah), sistem mencapai konsensus bertahap dengan risiko yang dikendalikan oleh pengguna bisnis individu.

VERIFIKASI DAN KONSENSUS

Kami memperkenalkan di sini konsep “verifikasi berbasis konteks” ke diskusi blockchain. Untuk menerangi, pertimbangkan Bitcoin atau implementasi blockchain lain yang ada. Mereka terutama menggunakan algoritme bukti yang ditetapkan (misalnya PoW) untuk merakit blok dari waktu ke waktu dan untuk mencapai konsensus tentang blok mana dan rantai mana yang merupakan kebenaran umum yang disepakati.

Di Dragonchain, dengan persetujuan berbasis konteks, kami menambahkan dimensi lain ke desain itu. Jadi tingkat pertama dicapai dalam konteks bisnis murni, yaitu dengan logika bisnis yang diterapkan untuk memberikan persetujuan transaksi dan logika sistem untuk mengatur transaksi tersebut ke dalam blok-blok yang dirantai bersama. Blok-blok ini akan memiliki bukti abstrak yang terintegrasi seperti PoW, PoS, atau kepercayaan. Verifikasi tingkat pertama ini dapat dianggap analog dengan blockchain lainnya.

Saat konteks verifikasi lain ditambahkan, kami melihat nilai tambah bahkan pada sistem berbasis kepercayaan.

TINGKAT 1 – VERIFIKASI BISNIS (PERSETUJUAN)

Fungsionalitas persetujuan diimplementasikan dan dikonfigurasi oleh integrator bisnis. Ini adalah penempatan untuk integrasi nilai “dunia nyata”. Logika bisnis yang ditentukan oleh organisasi atau pengguna platform blockchain dikonfigurasi untuk dieksekusi oleh node blockchain.

Di sini juga di mana muatan transaksi didefinisikan oleh bisnis sebagai apa yang dibutuhkan untuk tujuan mereka.

Transaksi diatur dan diteruskan ke logika bisnis yang disediakan yang akan menentukan persetujuan atau penolakan. Transaksi yang disetujui akan dirangkai menjadi “blok” yang secara umum disebut sebagai “catatan verifikasi”.

Bidang muatan dari setiap transaksi dapat dilucuti sebelum atau setelah merakit blok terakhir untuk mempertahankan kendali atas distribusi data bisnis yang sebenarnya. Artinya, tidak ada data muatan bisnis yang akan dicairkan sebagai bagian dari proses konsensus, dan data

akan tetap lokal pada node Level 1 kecuali jika pemilik bisnis secara eksplisit mendorong data ke node lain (misalnya untuk pencadangan/DR), atau secara eksplisit mengizinkan node yang berwenang untuk menarik data melalui feed langganan.

TINGKAT 2 – VERIFIKASI PERUSAHAAN (VALIDASI)

Konteks ini didefinisikan Enterprise atau jaringan yang luas, dan memeriksa validitas transaksi blok dan individu dalam bentuk, tanda tangan, dan elemen data yang diperlukan.

Elemen terverifikasi:

1. Blok (rekaman verifikasi) konstruksi dan tanda tangan
2. Tanda tangan transaksi individu
3. Elemen tajuk transaksi individual (bahwa semua bidang tajuk yang diperlukan ada) Node Level 2 akan mengumpulkan catatan verifikasi baru yang akan berisi:
4. Daftar transaksi yang sah dan daftar transaksi yang tidak sah, dan dengan cara ini memberikan suara pada keabsahan masing-masing transaksi.
5. Hash dari catatan Level 2 sebelumnya yang dibuat oleh node ini untuk node asal yang sama (Level 1) (sehingga menciptakan blockchain Level 2)
6. Hash dari blok Level 1 yang divalidasi (sehingga memberikan dimensi kedua ke blockchain)
7. Informasi identitas pemilik simpul
8. Lokasi penyebaran node (pusat data)
9. Informasi otoritas manajemen kunci simpul

TINGKAT 3 – VERIFIKASI KEANEKARAGAMAN JARINGAN

Didefinisikan di seluruh perusahaan, node Level 3 akan memverifikasi keragaman verifikasi validasi (Level 2). Artinya, node Level 3 akan memeriksa kriteria berikut:

1. Hitungan catatan verifikasi Level 2 telah diterima
2. Bahwa catatan tersebut berasal dari (jumlah yang dapat dikonfigurasi) dari unit bisnis yang unik
3. Bahwa catatan tersebut berasal dari (jumlah yang dapat dikonfigurasi) dari lokasi penyebaran yang unik
4. Bahwa catatan tersebut berasal dari (jumlah yang dapat dikonfigurasi) dari otoritas manajemen kunci yang unik

Konteks verifikasi ini akan memastikan bahwa validasi transaksi berasal dari sumber terdistribusi yang cukup beragam. Ini juga menyediakan kontrol dan pengukuran efek jaringan dan menyediakan keamanan terdistribusi karena penyerang akan diperlukan untuk menyerang beberapa sistem, bisnis, dan pusat data untuk merusak data yang ada.

Node Level 3 akan mengumpulkan catatan verifikasi baru yang berisi:

1. Kriteria yang tersisa terpenuhi (misalnya, jumlah catatan verifikasi Level 2, kumpulan unit bisnis, kumpulan pusat data).
2. Hash dari catatan Level 3 sebelumnya yang dibuat oleh node ini untuk node asal yang sama (Level 1) (sehingga menciptakan blockchain Level 3)
3. Hash dari catatan verifikasi Level 2 yang melewati kriteria (sehingga memberikan dimensi kedua ke blockchain)

LEVEL 4 – VERIFIKASI MITRA EKSTERNAL (NOTARI)

Luas jaringan yang ditentukan (Enterprise+), node level 4 akan menyediakan fungsionalitas notaris untuk proses konsensus. Dihosting oleh mitra eksternal, node level 4 akan secara kriptografis menandatangani catatan verifikasi level 3 apa pun yang diterimanya. Fungsi ini memungkinkan node Level 4 bertindak sebagai saksi independen untuk verifikasi level 3.

TINGKAT 5 – TITIK PEMERIKSAAN UMUM

Node Level 5 akan menyediakan jembatan ke satu atau lebih blockchain publik dan memungkinkan klien untuk berinteraksi dengan mereka (misalnya Bitcoin, Ethereum, Litecoin, dll.).

Fitur penting yang akan disediakan ini adalah pos pemeriksaan, atau menempatkan hash artefak untuk “bukti keberadaan” di blockchain publik. Untuk operasi checkpointing, node Level 5 akan menerima transaksi, verifikasi blok level apa pun, string arbitrer, atau hash arbitrer. Argumen akan di-hash dan hash ini ditambahkan ke transaksi yang ditempatkan di blockchain publik.

Keberadaan hash ini dapat digunakan untuk membuktikan bahwa artefak itu ada dan pada keadaan tertentu menggunakan data blockchain publik. Sebuah organisasi dapat menggunakan bukti ini untuk mengukur dan mengurangi risiko berdasarkan perkiraan atau perhitungan daya hash yang dikeluarkan sejak saat itu (dalam kasus bukti kerja blockchain). Misalnya, transaksi $ 2 Juta dapat diteruskan ke node Level 5 untuk ditempatkan sesegera mungkin di blockchain Bitcoin, dan pada suatu saat nanti, suatu pihak dapat menggunakan informasi itu sebagai sumber untuk mengukur jumlahnya.

hashpower yang telah dikeluarkan sejak saat itu, hitung probabilitas bahwa penyerang dapat berhasil memalsukan blok Bitcoin yang diberikan persentase tertentu dari hashpower global, dan memperkirakan atau memperkirakan biaya untuk mengeluarkan hashpower tersebut (serta pengorbanan perangkat keras dan/ atau mata uang karena jaringan runtuh). Jika proses ini menghasilkan evaluasi risiko yang memuaskan bagi bisnis, transaksi dapat dipercaya dan diterima.

Aspek penting lainnya dari fungsi jembatan publik adalah kemampuan untuk melacak aset antara pihak swasta dan publik. Yaitu, mengingat mata uang internal yang diterapkan untuk menggunakan alamat Bitcoin (lihat bagian mata uang di tempat lain dalam dokumen ini), token dapat diterbitkan pada Bitcoin menggunakan API atau layanan publik dan token ini dapat hidup di blockchain pribadi dan blockchain publik Bitcoin. Pemilik kunci atau dompet akan dapat mentransfer token atau aset dengan interaksi blockchain publik atau pribadi. Node Level 5 dapat digunakan untuk melacak aset ini di antara blockchain serta menjaganya tetap sinkron satu sama lain.

TINGKAT X – VERIFIKASI KONTEKS KEPEMILIKAN

Seharusnya mungkin bagi bisnis, Perusahaan, atau seluruh jaringan untuk menentukan konteks verifikasi khusus dan menjalankannya untuk memenuhi kebutuhan bisnis.

Sebuah node dapat dikonfigurasi untuk menjalankan konteks verifikasi arbitrer yang akan dipicu dengan cara berikut:

1. Dengan menerima siaran dari node lain (dalam fase berurutan atau tidak berurutan)
2. Dengan pemicu berjangka waktu atau periodik (misalnya cron)
3. Dengan pemberitahuan melalui pola pengamat

KONSEP BLOCKCHAIN ​​DARI BLOCKCHAIN

Arsitektur ini mungkin paling baik dipahami sebagai “blockchain dari blockchains”. Artinya, node fungsi persetujuan bisnis (lihat Level 1 di bawah) berfungsi seperti blockchain standar pada level 1 dimensi. Namun, setiap bisnis umumnya akan memiliki node sendiri untuk melakukan pekerjaan ini, masing-masing dengan blockchainnya sendiri. Di sinilah blockchains ini digabungkan sehingga konsensus tercapai.

MATA UANG

Arsitektur ini harus mampu multi-mata uang. Artinya, umumnya jika kasus penggunaan mata uang didefinisikan, bahwa sebuah node dapat mendefinisikan mata uang dan mendukung penggunaannya. Lebih dari satu mata uang dapat digunakan secara bersamaan di jaringan secara keseluruhan.

Meskipun demikian, arsitektur ini tidak boleh mendefinisikan mata uang “dasar”, atau mata uang yang dijalankan oleh sistem itu sendiri. Jika kasus penggunaan seperti itu muncul (karena memang sangat mungkin untuk melihat nilai dalam ketersediaan mata uang di mana node dapat membayar satu sama lain untuk verifikasi), adalah filosofi arsitektur ini bahwa sebuah node harus dikonfigurasi untuk membuat dan memeliharanya. mata uang. Ini akan memungkinkan pengembangan pasar yang lebih fleksibel daripada upaya apa pun untuk mendefinisikannya di awal pengembangan platform.

Implementasi arsitektur ini kemungkinan harus menyediakan satu atau lebih mata uang templated atau dikonfigurasi untuk kemudahan penyebaran. Implementasi tersebut dapat menentukan hal-hal seperti algoritma penambangan atau pencetakan, pengalamatan, manajemen dompet, dan lain-lain. Implementasi tersebut juga harus dapat diperluas oleh pengguna untuk eksperimen dan penyesuaian lebih lanjut.

PEMODELAN MATA UANG

Arsitektur memungkinkan pengguna untuk memodelkan mata uang dan menghasilkan uang di akhir desain mereka. Dimungkinkan bagi pengguna untuk menempatkan informasi dari banyak sumber di atas blockchain, mengawasi penggunaannya dari waktu ke waktu, dan menentukan nilainya berdasarkan prioritas bisnis dan pelanggan. Pada titik ini, aset dan aktivitas dapat dimonetisasi dan algoritme penambangan atau pencetakan dapat dikembangkan yang akan memberi insentif kepada karyawan, tim, atau pelanggan bisnis.
Proses kuantifikasi, monetisasi, dan insentif ini mungkin merupakan salah satu penyetelan tanpa akhir, tetapi akan memberikan sistem ekonomi yang transparan.

Ada potensi kerangka kerja ini untuk memberikan kelincahan dalam organisasi di mana penyedia data diaktifkan untuk menyediakan akses segera dan awal ke data penelitian, laporan, dan informasi lain untuk proyek yang tidak akan pernah melihat data tersebut, karena biasanya memerlukan top-down persetujuan organisasi dengan biaya dan risiko yang besar. Penggunaan data tersebut dapat dilacak dan nilainya ditentukan, yang mengarah pada monetisasi langsung dan mekanisme pendanaan dari bawah ke atas.

ALAMAT BITCOIN

Implementasi dasar kemungkinan harus default (setidaknya untuk masa mendatang) untuk memanfaatkan pengalamatan Bitcoin dan kriptografi untuk memanfaatkan ekosistem Bitcoin eksternal yang terus berkembang. Misalnya, penggunaan kriptografi Bitcoin dalam mata uang pribadi akan memungkinkan penggunaan dompet penandatanganan perangkat keras secara transparan untuk penggunaan internal (misalnya KeepKey, Trezor, Ledger). Contoh lain adalah tokenisasi, di mana seseorang dapat secara langsung mengintegrasikan teknologi penyedia tokenisasi Bitcoin untuk digunakan dengan blockchain internal (misalnya Counterparty atau Tokenly).

INTEROPERABILITAS

Dengan bidang header kelas transaksi, dimungkinkan untuk membungkus transaksi cryptocurrency asing dalam transaksi blockchain pribadi.

KONTRAK CERDAS

Banyak pertanyaan muncul sehubungan dengan “kontrak pintar” berbasis blockchain…

KELENGKAPAN TURING

Bagian atas daftar ini adalah kelengkapan Turing. Bitcoin sengaja tidak menyelesaikan Turing. Ini serumit yang diperlukan untuk menyediakan kemampuan yang dibutuhkan untuk aplikasinya.

Beberapa implementasi blockchain seperti Ethereum adalah Turing selesai. Hal ini memungkinkan beberapa aplikasi yang sangat menarik, namun membawa beberapa risiko dan kesulitan dalam implementasi. Kontrak cerdas harus dijalankan dalam wadah khusus dan terverifikasi atau mesin virtual untuk memastikan hasil yang deterministik tidak peduli perangkat keras atau sistem operasi tempat node berjalan. Berbagai aspek dari kontrak pintar harus dipantau (misalnya loop) untuk kegagalan atau tindakan yang tidak terduga atau tidak sah.

TRANSAKSI, ATOMISITAS, DAN ROLLBACK

Sistem kontrak pintar mungkin perlu menyediakan beberapa tingkat transaksi terkontrol atau otomatis dan kemampuan rollback untuk memastikan bahwa tindakan apa pun hanya akan berlaku jika seluruh operasi transaksi berhasil diselesaikan.

EKSEKUSI TERDISTRIBUSI

Di mana kontrak pintar dieksekusi? Apakah pada node terdistribusi (memanggil)?

KONTRAK PINTAR DRAGONCHAIN

Arsitektur panggilan untuk definisi kode “konteks persetujuan” untuk dikonfigurasi atau digunakan pada node bisnis Level 1. Kode persetujuan ini dapat dianggap sebagai kontrak pintar. Secara default, kontrak pintar ini hanya akan dijalankan pada node Level 1 tersebut, dan di bawah kendali langsung pemilik bisnis. Ini menyediakan antarmuka klien/server yang familier untuk pembuatan kontrak cerdas, dan menyederhanakan evaluasi risiko. Vektor serangan lebih umum dan dikenal oleh para insinyur modern.
Kelengkapan turing disediakan sama seperti dalam platform layanan web apa pun.

Kontrak pintar dapat didistribusikan dengan baik, dan dapat dieksekusi berdasarkan pembayaran per permainan. Dalam hal ini, banyak risiko dengan kontrak pintar yang dijelaskan di atas berlaku, namun dapat diasumsikan bahwa para pihak akan memiliki hubungan kepercayaan di dalam organisasi untuk dimanfaatkan dan penyediaan kode dapat mencakup perjanjian hukum yang diperlukan.

Dengan cara yang hampir sama, sebuah grup dapat menyelenggarakan kontrak pintar sebagai bisnis dukungan TI, dan menyediakan berbagai rencana untuk tolak bayar/pembayaran.

Kontrak cerdas dapat digunakan pada node dengan cara berikut:

Di-hardcode dalam basis kode bercabang
Dikonfigurasi (dengan kode kontrak pintar yang diterapkan pada sistem)
Disampaikan melalui blockchain (admin akan mengirim transaksi multi-signed dengan kontrak pintar, tanggal mulai, dll.)

UMPAN DATA BERLANGGANAN

Karena muatan transaksi dihilangkan sebelum siaran apa pun dalam proses konsensus, node akan membagikan data bisnis seperlunya melalui umpan data langganan. Ini sama dengan mekanisme push atau pull dimana beberapa subset dari transaksi node secara terus menerus diumpankan ke node lain.

Dalam kasus di mana sebuah node membutuhkan data node lain untuk “menumpuk” dengan datanya sendiri untuk melayani pelanggan, node tersebut akan mengonfigurasi untuk meminta akses dari “node asal” yang memiliki data tersebut. Permintaan ini mungkin datang dengan informasi otentikasi atau otorisasi dan node asal dapat menyetujui atau menolak permintaan tersebut. Node yang meminta juga dapat memberikan kriteria untuk umpan data seperti hanya jenis transaksi tertentu, hanya transaksi yang telah melampaui tingkat verifikasi tertentu di jaringan, atau hanya melibatkan identitas tertentu. Dengan cara ini, node yang meminta akan memiliki cache lokal hanya dari data yang dibutuhkannya, dan node tersebut akan dapat menjawab pelanggannya dengan keyakinan bahwa data tersebut tidak berubah dan diverifikasi tanpa perlu menjangkau layanan bisnis asal di masa depan.

Dalam kasus di mana node asal ingin mendistribusikan datanya (yaitu untuk pencadangan atau pemulihan bencana), node tersebut dapat membayar layanan tersebut dan terus mendorong data ke node tersebut. Node cadangan akan dapat memverifikasi bahwa data bebas dari kesalahan setelah diterima dan diaudit secara berkala.

MANAJEMEN JARINGAN

Untuk sistem jaringan blockchain, banyak elemen khas yang harus ada seperti penyediaan, penemuan, pemeliharaan node yang tersedia dan berkualitas, dll. Namun arsitektur akan mengambil beberapa posisi filosofis pada konfigurasi dan pemeliharaan jaringan.

Semua pertimbangan untuk manajemen jaringan dan komunikasi dalam arsitektur ini harus dibuat dari konteks node individu. Keputusan seperti node mana yang akan dihubungkan harus merupakan keputusan terdesentralisasi yang dibuat oleh setiap node secara independen. Mungkin ada mekanisme untuk manajemen pusat petunjuk atau daftar awal dari node yang tersedia dijamin dalam suatu Perusahaan, tetapi tidak ada upaya harus dilakukan untuk memusatkan persyaratan koneksi jaringan.

DISTRIBUSI DATA

Secara default, tidak ada data muatan transaksi (bisnis) yang harus meninggalkan node asal (memiliki) atau disebarkan ke seluruh jaringan. Sebagai bagian dari konsensus dan komunikasi jaringan, semua muatan transaksi harus dihapus sebelum disiarkan.

Hanya ketika secara eksplisit diotorisasi oleh node asal, muatan dan transaksi penuh disebabkan untuk disiarkan ke node yang diotorisasi.

PENEMUAN NOD

Penemuan node harus dilakukan melalui permintaan peer to peer.

JARINGAN PASAR

PENTING: Setiap gagasan tentang pasar atau mata uang yang dengannya node dapat memperdagangkan atau menyewakan verifikasi tidak boleh diterapkan dalam infrastruktur sistem, melainkan sebagai implementasi mata uang tambahan pada node dalam jaringan blockchain. Dengan cara ini, arsitektur akan tetap fleksibel dan terbuka untuk ide-ide baru atau persyaratan yang tidak terduga.

PENILAIAN KUALITAS NODE

Sebuah node harus melacak dan memastikan kualitas rekan individu yang terhubung dan terputus. Mempertimbangkan peer yang saat ini terhubung dan terputus secara terpisah, sebuah node harus melacak atribut seperti:

Latensi rata-rata koneksi (dinilai secara berkala) Tingkat keberhasilan penandatanganan
Jumlah siaran ulang Waktu verifikasi rata-rata
Menyebarkan lokasi (untuk kriteria keragaman) Pemilik (untuk kriteria keragaman) Upaya koneksi gagal Upaya koneksi terakhir
Keberhasilan simpul dalam mendapatkan tingkat verifikasi berbasis konteks lebih lanjut

Sebuah node harus melakukan penilaian berkala terhadap node yang terhubung lebih sering daripada node yang tidak terhubung, namun dalam rentang waktu yang wajar, node tersebut harus menilai kualitas node yang terputus agar memiliki kecerdasan yang diperlukan untuk memprioritaskan koneksi peer jika sebagian besar node yang terhubung menjadi tidak tersedia.

PENERIMAAN VERIFIKASI

Siaran catatan verifikasi ke simpul verifikasi tingkat yang lebih tinggi harus memberikan pesan tanda terima yang memberitahukan keberhasilan atau kegagalan, dan jika berhasil, harus menyertakan catatan verifikasi yang ditandatangani oleh simpul tingkat yang lebih tinggi. Mekanisme yang sama ini harus diteruskan lebih jauh ke bawah untuk mencapai simpul asal. Meskipun merupakan pertimbangan desain, sesuatu dalam cara balasan asinkron ke panggilan siaran lain mungkin merupakan mekanisme yang tepat untuk menyediakan kemampuan tersebut.

PILIHAN IMPLEMENTASI

Panggilan layanan RESTful kustom (mis. Apache Thrift)
Kerangka kerja basis data terdistribusi dengan replikasi

INTEROPERABILITAS DAN STANDAR YANG DIUSULKAN

Ada banyak jalan yang perlu dipertimbangkan untuk pertanyaan interoperabilitas dengan sistem blockchain lainnya.

CHECKPOINTING & PEMBUNGKUS

Seseorang dapat memilih untuk menghubungkan transaksi atau artefak lainnya melalui pos pemeriksaan (lihat Level 5 – Pos Pemeriksaan Publik di atas) atau dengan membungkus transaksi atau artefak asing dalam transaksi Dragonchain (lihat tajuk transaksi mata uang asing di atas).

SUB KONSENSUS

Sebuah bisnis dapat memilih untuk menggunakan blockchain lain di setiap tingkat proses verifikasi. Misalnya, untuk memberikan implementasi persetujuan Level 1 yang terdesentralisasi, seseorang dapat memilih untuk menggunakan Bitcoin atau blockchain berbasis bukti kerja lainnya untuk mencapai konsensus tentang transaksi mata uang.
ADOPSI

Arsitektur harus diharapkan untuk mengadopsi standar saat tersedia.

Standarisasi blockchain W3C Blockchain Community Group (https://github.com/w3c/blockchain/blob/master/standards.md) Catatan Standarisasi Blockchain Disney (https://dragonchain.github.io/blockchain-standardization)

Dimana anda bisa membeli Dragonchain coin ?

Dragonchain memiliki maksimal pasokan 433.494.437 koin DRGN.

Jika Anda ingin tahu di mana membeli Dragonchain dengan kurs saat ini, pertukaran cryptocurrency teratas untuk perdagangan saham Dragonchain saat ini adalah FTX, KuCoin, Gate.io, HitBTC, dan SushiSwap.

Referensi : Dragonchain Whitepaper