Apa itu ProximaX, XPX Coin adalah

Apa itu ProximaX, XPX Coin ?

ProximaX adalah infrastruktur dan platform pengembangan tingkat perusahaan yang mengintegrasikan teknologi blockchain dengan lapisan layanan terdistribusi dan terdesentralisasi: penyimpanan, streaming, database, dan Supercontract (kontrak pintar yang ditingkatkan). Dibangun di atas teknologi yang telah terbukti, ini adalah platform all-in-one yang mudah digunakan yang dapat diperluas dengan lebih banyak lapisan layanan tanpa mengurangi kinerja. Platform ProximaX tersedia dalam konfigurasi jaringan pribadi, publik, dan hybrid.

ProximaX, XPX Coin

Platform ProximaX Sirius terdiri dari beberapa server yang didistribusikan dalam jaringan. Ini mengikuti desain “hub and spoke” di mana komponen inti adalah blockchain, atau “hub,” dan komponen lainnya adalah lapisan layanan, atau “jari-jari”. Lapisan layanan terdiri dari P2P dan penyimpanan terdistribusi, streaming, database, dan Supercontract di mana:

• Semua penyimpanan, pengiriman pesan, dan transaksi dienkripsi
• Streaming mencakup data teks, video, dan suara
• Semua acara diberi stempel waktu di blockchain
• Eksekusi bisnis dan proses otomatis dilakukan melalui Supercontract off-chain
• Lapisan layanan tambahan dapat ditambahkan ke ProximaX Sirius untuk menawarkan lebih banyak fungsi. Lapisan ini dapat berupa apa saja mulai dari layanan khusus seperti kecerdasan buatan hingga komputasi terdistribusi untuk pengurutan genom.

Dengan perluasan lapisan layanan, bagaimanapun, kinerja lapisan individu tetap tidak terpengaruh. Ini mirip dengan beberapa set node server jaringan yang berjalan secara paralel dan disatukan oleh blockchain pada intinya. Setiap set node jaringan melakukan fungsi tertentu, dan kekuatan fungsi tumbuh dengan lebih banyak node server terpasang.

Lapisan Platform Sirius

Rantai Sirius
Blockchain perusahaan canggih dengan fitur bawaan seperti multilayer-multisig, transaksi tarik, transaksi agregat, dan kemampuan lintas rantai untuk mendukung solusi canggih.

Penyimpanan Sirius
Sistem berbagi file terdistribusi yang diaktifkan blockchain di mana perusahaan dapat menyimpan dan berbagi file dengan mulus di seluruh dunia.

Superkontrak
Kontrak digital off-chain yang dapat dijalankan untuk mengotomatisasi proses bisnis, meminimalkan kesalahan, dan memaksimalkan efisiensi.

Aliran Sirius
Infrastruktur streaming yang tangguh untuk menangani streaming data yang sangat penting dengan waktu henti yang hampir nol.

Platform Sirius

Platform pengembangan dan infrastruktur Blockchain menggambar ulang struktur dan back-end banyak industri seperti yang kita kenal sekarang. Namun, platform ini biasanya
hanya terdiri dari blockchain yang digunakan terutama untuk transaksi nilai. ProximaX mengubah ini dengan secara signifikan memperluas utilitas blockchain untuk juga melayani transaksi data.

ProximaX Sirius adalah platform yang melampaui protokol blockchain tradisional dengan mengintegrasikan blockchain dengan penyimpanan terdistribusi dan terdesentralisasi, streaming, kontrak, dan lapisan layanan database1 yang tersedia dalam konfigurasi jaringan pribadi, publik, hibrida, dan konsorsium.

Platform ini memiliki beberapa server yang didistribusikan dalam jaringan yang mengikuti desain “hub-and-spoke” di mana komponen penting adalah blockchain, yang mewakili “hub,” dan semua lapisan layanan lainnya mewakili “jari-jari” yang disatukan oleh blockchain. Desain ini memungkinkan skalabilitas karena memfasilitasi penambahan lebih banyak layanan inti di masa mendatang tanpa mengorbankan kinerja platform.

Setiap lapisan memiliki ekosistem aktor simpulnya sendiri, menyediakan layanan unik yang dibungkus dalam antarmuka pemrograman aplikasi (API) yang dapat diakses dan kit pengembangan perangkat lunak (SDK) yang tersedia dalam berbagai bahasa pengkodean umum

Utilitas superior dan fleksibilitas ProximaX Sirius memungkinkan pengembang untuk membangun solusi apa pun secara vertikal di atas, termasuk aplikasi untuk perbankan dan pembayaran, identitas digital dan KYC, streaming video dan obrolan, dan permainan.

Lapisan layanan inti:

Rantai Sirius
Lapisan blockchain, Sirius Chain, adalah cabang dari blockchain open-source baru yang disebut Catapult. ProximaX memilih Catapult karena fitur unik tingkat perusahaan (lihat bagian 3.2.) yang tidak tersedia di blockchain lain. ProximaX meningkatkan kemampuan Catapult dengan mengintegrasikan protokol baru sehingga Sirius Chain dapat melakukan “pengangkatan berat” yang diperlukan dari “hub.”

Penyimpanan Sirius

Lapisan penyimpanan, Sirius Storage, memungkinkan kontributor publik untuk memonetisasi ruang penyimpanan mereka yang tidak terpakai. Fitur termasuk pembuatan Drive terdesentralisasi, unggahan data, modifikasi data, dan unduhan data. Protokol memungkinkan pengambilan keputusan kolektif untuk pembayaran, verifikasi, sinkronisasi, dan pengunduhan anonim.

Aliran Sirius
Lapisan streaming, Sirius Stream, memungkinkan kontributor publik untuk memonetisasi bandwidth internet mereka yang tidak terpakai untuk streaming langsung. Fitur termasuk pembuatan dan transmisi streaming langsung terdesentralisasi. Protokol memungkinkan sponsorship dan distribusi konten massal.

Superkontrak
Lapisan kontrak, bernama Supercontract, adalah versi perbaikan dari kontrak pintar tradisional, di mana logika yang mengeksekusi sendiri terletak di luar rantai di Sirius Storage untuk mencegah jaringan blockchain menjadi “membengkak” dan memengaruhi kinerjanya.
Node khusus menjalankan Supercontract daripada semua node jaringan, sehingga mengurangi pekerjaan komputasi. Tidak seperti kontrak pintar tradisional, pihak yang berwenang dapat menghentikan, mengubah, dan memulai kembali Supercontract dengan cepat dan mudah setelah mencapai konsensus.

Tinjauan Konten
Tinjauan Konten adalah lapisan tambahan yang memungkinkan konten jaringan dikategorikan, dapat dicari, disensor, dan dilarang.

Tokenomics

Token
Seperti semua jaringan publik yang terdesentralisasi, desain dan implementasi tokenomik sangat penting untuk keberlanjutan dan tata kelola mereka. Tujuan dari tokennomics adalah untuk menciptakan kerangka insentif ekonomi umum untuk “pekerjaan yang dilakukan” oleh kontributor jaringan, diikat bersama dengan sistem reputasi.

Prinsip dasar yang diadopsi dalam desain tokennomics ProximaX meliputi:

• Self-organisasi dan sinergi antara beberapa elemen sistem.
• Kemampuan beradaptasi terhadap taktik yang merugikan dan serangan internal.
• Pembuatan Unit Layanan yang digunakan untuk mengukur penyediaan layanan inti platform.
• Infrastruktur yang dapat diperluas untuk memfasilitasi plug-in untuk layanan inti dan tokenomik baru.
• Pembuatan solusi ekosistem dan aplikasi yang akan memanfaatkan blockchain untuk menciptakan lebih banyak transaksi, dengan XPX sebagai penggerak ekonomi inti.

Ekosistem token ProximaX Sirius terdiri dari:

Intern:

• Token asli (XPX): Memberi daya pada lapisan blockchain dan digunakan untuk membayar layanan platform.
• Unit Layanan: Unit ukuran yang dapat diukur untuk penyediaan layanan platform.
• Sirius Digital Assets3 (SDA): Setiap pengguna dapat membuat jenis SDA baru, baik untuk mendukung ekonomi internal aplikasi terdesentralisasi (DApp), mewakili keamanan digital (token keamanan), atau objek yang dapat dipertukarkan atau tidak dapat dipertukarkan, seperti non-fungible token (NFT).

Luar:

• Fiat dan mata uang kripto lainnya: Pemrogram dapat mengintegrasikan gateway pembayaran apa pun, misalnya, menukar XPX atau SDA ke jaringan lain dan sebaliknya.

Koin Asli (XPX)

Protokol blockchain menentukan mata uang asli yang akan beredar. Untuk Sirius Chain, ini adalah XPX. Dengan beberapa layanan platform yang terkait dengan protokol blockchain, pengguna yang ingin menggunakan layanan platform harus membayar dalam XPX.

Unit Layanan
XPX digunakan untuk berlangganan jaringan publik ProximaX Sirius dengan imbalan Unit Layanan melalui pertukaran internal otomatis. Unit Layanan sebanding dengan apa yang oleh beberapa rantai disebut sebagai token Gas yang digunakan untuk menjalankan kontrak pintar. Di ProximaX Sirius, beberapa layanan terintegrasi mendapat manfaat dari penggunaan beberapa jenis “Gas”.

Jenis Unit Layanan:

• Storage Unit (SO) untuk penyimpanan data: Satu unit mewakili kemampuan untuk menyimpan data. 1 SO sesuai dengan 1 GB ruang yang disimpan untuk jangka waktu empat minggu.
• Streaming Unit (SM) untuk streaming data: Satu unit mewakili jumlah data yang ditransfer antara node atau node dan konsumen. 1 SM sesuai dengan 1 GB yang dialirkan.
• Unit Superkontrak (SC) untuk menjalankan Superkontrak: 1 SC sesuai dengan 1 miliar kode operasi Superkontrak (opcode).
• Unit Tinjauan (RW) untuk umpan balik dan tinjauan konten: 1 RW sesuai dengan 1 ulasan konten.

Pengguna Unit Layanan:

1. Konsumen: Mereka mengkonsumsi layanan dan melakukan pembayaran untuk layanan tersebut.
2. Kontributor jaringan: Mereka memberikan layanan kepada konsumen dengan imbalan pembayaran untuk menyediakan layanan ini.
3. Konsensus internal: Digunakan untuk mewakili kapasitas dan kebenaran node untuk menyediakan layanan.

Pendekatan ini memungkinkan ProximaX Sirius memiliki ekonomi dalam multidimensi di mana Unit Layanan memberi daya pada layanan yang diberikan oleh aktor simpul yang berbeda. Ini juga memfasilitasi perluasan layanan platform di masa depan.

Sirius DEX

Sirius DEX adalah pertukaran terdesentralisasi (DEX) yang dibangun untuk memfasilitasi pertukaran otomatis antara token asli (XPX) dan Unit Layanan. Sirius DEX akan diperluas untuk menyertakan pertukaran antara SDA di tahap selanjutnya.

Selain membuat layanan melalui aplikasi secara vertikal di atas platform, pengembang juga dapat membuat layanan inti baru dan ekonomi token yang sesuai menggunakan infrastruktur plugin Sirius yang dapat diperluas. Layanan inti baru dapat menggunakan Sirius DEX untuk menukar jenis Unit Layanan baru. Contohnya adalah pembuatan Unit Layanan baru untuk layanan inti mesin pencari.

Sirius DEX menggunakan algoritme nilai tukar yang dapat disetel untuk menjaga harga layanan platform tetap stabil dan kompetitif. Misalnya, karena penyimpanan data dan bandwidth internet menjadi lebih murah secara universal dari waktu ke waktu, harga Unit Layanan akan turun.

Fitur ProximaX

Akun
Akun adalah status yang dapat berubah yang disimpan di Sirius Chain yang diatur oleh pasangan kunci: kunci privat dan publik. Dengan kata lain, Anda memiliki “deposit box” di blockchain, yang hanya dapat Anda modifikasi dengan kunci pribadi Anda. Seperti namanya, pemilik akun harus merahasiakan kunci pribadi. Siapa pun yang memiliki akses ke akun tersebut akan dapat mengontrol akun tersebut.

ruang nama
Namespace memungkinkan Anda membuat nama on-chain yang unik dan mudah diingat untuk akun dan SDA Anda. Namespace dimulai dengan memilih nama yang belum dipesan, mirip dengan nama domain internet. Dengan mengumumkan transaksi alias, Anda dapat mengaitkan Namespace dengan akun atau pengenal (ID) SDA. Namespace bekerja di bawah kontrak sewa yang dijalankan secara on-chain, dibayar dalam XPX, dan dengan periode durasi yang dihitung menurut tinggi blok.

aku aku aku. Sirius Digital Asset (SDA)
Anda dapat membuat aset digital apa pun di platform. SDA adalah kontrak bawaan yang ditentukan pada protokol blockchain untuk memungkinkan konsumen membuat representasi digital.

Misalnya, SDA dapat mewakili:

• mata uang;
• pengukuran konsumsi;
• aset berwujud;
• aset yang tidak dapat dipertukarkan;
• poin hadiah;
• instrumen keuangan, mis. derivatif atau obligasi;
• pemungutan suara; atau
• bendera status.

Anda dapat mendefinisikan SDA dengan mengaitkannya dengan Namespace yang Anda miliki dan menyesuaikan propertinya, yang meliputi:

• dapat dibagi – jumlah tempat desimal;
• durasi – waktu kedaluwarsa atau tidak pernah kedaluwarsa;
• pasokan awal;
• pasokan mutabilitas (yaitu, kuantitas berubah); dan
• transferabilitas – dapat dipindahtangankan secara bebas atau hanya dapat dipindahtangankan antara penerbit dan penerima.

Transaksi Multi-Tanda Tangan Multi-level
Multi-signature adalah perjanjian cosignatory (kontrak sekali pakai) antara penandatangan akun (misalnya, berapa banyak yang perlu ditandatangani untuk melaksanakan transaksi atau menambah/menghapus penandatangan). Multi-level Multi-signature memungkinkan Anda untuk memiliki beberapa tingkat perjanjian antara cosignatories lainnya, sehingga berguna untuk proses persetujuan yang komprehensif. Perjanjian multi-tanda tangan memiliki waktu kedaluwarsa untuk dieksekusi, setelah itu akan berakhir.

Transaksi Agregat
Transaksi agregat menggabungkan beberapa transaksi menjadi satu, memungkinkan pertukaran tanpa kepercayaan, escrow, dan logika lanjutan lainnya. Setelah semua penandatangan menandatangani transaksi, pertukaran dijalankan secara otomatis dan tidak dapat dibatalkan. Dalam konteks kami, semua transaksi ganda ini disebut “transaksi batin”. Transaksi internal ini dapat berupa semua jenis SDA, yaitu, dapat melibatkan XPX dan beberapa SDA lainnya dalam satu transaksi agregat. Oleh karena itu, transaksi agregat ini memberi kita mekanisme pertukaran yang sangat kuat. Salah satu contohnya adalah pertukaran NFT untuk XPX dan biaya komisi untuk pengantar dalam pengaturan tiga pihak di mana pembeli membayar XPX dan penjual menjual NFT dan agen pengantar mendapat biaya komisi. Ketika semua pihak menandatangani, tiga transaksi batin dicairkan sesuai, dengan NFT pergi ke pembeli, beberapa XPX pergi ke penjual dan sisa XPX pergi ke agen pengantar

Metadata
Anda dapat menentukan objek di Sirius Chain dengan menambahkan Metadata kustom ke transaksi, akun, Namespace, dan SDA. Ibaratkan ini sebagai catatan yang ditandai dengan objek transaksi.

Transaksi Lintas Rantai
Transaksi lintas rantai adalah pertukaran token antara dua blockchain. Juga disebut “pertukaran atom,” ini melibatkan penguncian dana di rantai pihak pengirim dan kemudian mengeluarkan token di rantai penerima.

Misalnya, transaksi dapat terjadi antara:

• rantai publik dan swasta; atau
• dua rantai pribadi; atau
• dua rantai publik Catapult, yang membuka layanan ProximaX Sirius ke ekosistem eksternal seperti blockchain Symbol4.

Konsensus

Seorang konsumen harus membayar XPX untuk menggunakan platform publik. Seorang Harvester akan menerima XPX sebagai biaya untuk menempa atau membuat blok blockchain baru. Setiap blok terdiri dari transaksi yang memiliki biaya terlampir. Protokol menambahkan biaya untuk membuat hadiah blok untuk Pemanen.

Seperti implementasi blockchain publik lainnya, ekosistem jaringan yang adil dan otonom akan membutuhkan mekanisme konsensus yang menentukan berbagai penghargaan yang diterima oleh aktor yang berpartisipasi untuk menyediakan layanan. Sirius Chain menggunakan Proof of Stake (PoS), Proof of Greed (PoG), dan Fast Finality.

Bukti Taruhan
Berbeda dengan konsensus Proof of Work (PoW) Bitcoin yang mengkonsumsi energi tinggi, Sirius Chain menggunakan PoS yang lebih efisien untuk memilih dan memberi penghargaan kepada produsen blok berikutnya. PoS Sirius Chain unik karena memberikan preferensi formasi blok kepada Pemanen dengan saham XPX tinggi dan mempertimbangkan keandalan node dan aktivitas kerja untuk mempromosikan jaringan yang sehat dan berkinerja.

Bukti Keserakahan
Sirius Chain menggunakan protokol konsensus Proof of Greed (PoG), algoritme reputasi yang diperluas yang membuat biaya transaksi lebih dekat dengan biaya sebenarnya dan mencegah Pemanen menjadi serakah.

Bagaimana itu bekerja:

1. Konsumen menawarkan biaya transaksi maksimum yang bersedia mereka bayar, yang dapat dihasilkan oleh perangkat lunak dompet secara otomatis.

2. Konsumen mengirim transaksi yang belum dikonfirmasi ke Pool Transaksi jaringan.
3. Pemanen mengambil transaksi yang belum dikonfirmasi dari pool, membentuk blok, dan mengajukan jumlah biaya yang tidak melebihi maksimum yang ditentukan oleh Konsumen.
4. Algoritme PoG memberikan Nilai Keserakahan, rasio antara biaya yang diajukan oleh Pemanen dan jumlah maksimum yang ditawarkan oleh Konsumen.
5. Semakin rendah biaya Harvester, semakin sedikit “serakah” itu dan semakin tinggi peluangnya untuk menghasilkan blok berikutnya dan mendapatkan biaya.

Finalitas Cepat
Protokol Sirius Chain PoS menggunakan mekanisme pemungutan suara berbobot Finalitas Cepat untuk mencapai konsensus dengan cepat dan efisien sebelum menambahkan blok baru ke dalam rantai. Metode ini memastikan blok bersifat “final” dan tidak dapat dibatalkan setelah dikomit ke blockchain, sehingga tidak mungkin Validator akan menyimpan versi blockchain yang berbeda.

Protokol secara acak memilih Pemanen untuk membentuk Komite yang melakukan pemungutan suara, memberikan preferensi kepada Pemanen dengan taruhan dan reputasi yang lebih tinggi berdasarkan jumlah blok yang telah mereka tandatangani. Pemanen yang tidak berkinerja baik yang tidak menghasilkan blok selama lebih dari satu tahun kehilangan kemampuan mereka untuk terpilih.

ProximaX merumuskan kerangka matematis untuk pemungutan suara berbobot untuk mengukur profil pemungutan suara Harvester untuk memastikan Komite berkinerja. Skema, yang berlaku setelah Komite terbentuk, memberikan skor kepada Pemanen berdasarkan ukuran taruhannya dan kontribusinya terhadap pelaksanaan protokol. Semakin tinggi skor Harvester, semakin besar bobot suaranya. Anggota Komite yang gagal menandatangani blok, karena salah atau offline, memiliki reputasi yang lebih rendah dan kemungkinan besar akan dikeluarkan dari Komite.

Pemungutan suara tertimbang – empat tahap:

Usulkan blok
Protokol memilih Anggota Komite (Pemanen) dengan Nilai Keserakahan terendah sebagai Pengusul Blok berikutnya. Nilai Keserakahan berasal dari biaya yang diterima dari blok yang terakhir diproduksi oleh Pemanen. Jika Pemanen belum menghasilkan satu blok, Nilai Keserakahan rendah diberikan untuk memfasilitasi partisipasi pendatang baru.

Pra-pemungutan suara
Pengusul Blok kemudian harus mengusulkan blok kepada Komite untuk penerimaan awal mereka, yang membutuhkan setidaknya dari Komite berdasarkan berat untuk memberikan suara awal. Jika Pengusul Blok tidak menyerahkan blok atau menyerahkan blok yang dibentuk secara tidak sah, Anggota Panitia memberikan suara nihil dan beralih ke Pengusul Blok terpilih berikutnya.

Pra-komit
Setiap Anggota Komite memeriksa bahwa setidaknya menurut beratnya telah memberikan suara awal mereka untuk melakukan pemblokiran terlebih dahulu.

Melakukan
Jika setidaknya berat telah berhasil melakukan pra-komit, blok tersebut berkomitmen ke blockchain dan ketinggian blok baru terbentuk.

Simulasi

Simulasi di bawah ini menunjukkan bahwa Pemanen dengan Nilai Keserakahan rendah memiliki peluang lebih baik untuk dipilih sebagai produsen blok dan mendapatkan bayaran.

Serangan
Protokol konsensus Sirius Chain melindungi jaringan dari potensi serangan.

saya. Serangan taruhan besar
Karena PoS memberikan preferensi kepada Harvester terkaya, potensi kerentanannya adalah Harvester jahat dengan 51% saham dapat meluncurkan Serangan Besar, memalsukan blok paling banyak, dan mengendalikan jaringan.

Algoritme PoS Sirius Chain mencegah hal ini dengan menciptakan spread yang adil saat memilih dan memberi penghargaan kepada Harvester, yang berarti bahwa Harvester dengan taruhan kecil pun memiliki peluang untuk mencatat bloknya di Sirius Chain.

Serangan tanpa biaya
Karena PoG menghukum Pemanen yang rakus, potensi kerentanannya adalah Pemanen yang jahat dapat menipu dan memanipulasi konsensus melalui Serangan Tanpa Biaya. Di sini, Pemanen membebankan biaya nol, memalsukan blok paling banyak, dan mengendalikan jaringan.

Algoritme PoG Sirius Chain menghilangkan kemungkinan Serangan Tanpa Biaya dengan memberikan preferensi kepada Pemanen yang mengambil biaya rata-rata daripada biaya minimum.

Transaksi Prioritas
Protokol kumpulan transaksi Sirius Chain menempatkan transaksi yang belum dikonfirmasi ke dalam antrian prioritas untuk mengelola volume transaksi yang tinggi dengan lebih baik.

Larangan Sementara & Permanen
Sirius Chain menggunakan protokol reputasi yang menghapus Validator yang tidak berfungsi, rusak, dan berbahaya dari jaringan.

Validator akan secara berkala menghentikan koneksi node yang ada untuk memberi ruang bagi interaksi baru untuk menghindari pembentukan kelompok yang terisolasi, sehingga mendorong desentralisasi. Pada setiap putaran pemilihan, Validator memeriksa usia semua koneksinya dan menjatuhkan yang terlama.

Komunikasi antara Validator dianggap sebagai interaksi, dan protokol menilai setiap interaksi sebagai “berhasil”, “netral”, atau “gagal”. Misalnya, ketika Validator memberikan data valid baru, interaksi ditandai sebagai “berhasil”. Jika tidak memberikan data, interaksinya “netral”. Jika tidak dapat berinteraksi karena konektivitas rendah atau memiliki data yang tidak valid atau lama, interaksi ditandai sebagai “gagal”. Validator dapat diblokir sementara atau permanen dari jaringan jika kegagalannya biasa dan parah.

Drive Penciptaan
Untuk membuat Drive, Pemilik Drive menggunakan perangkat lunak untuk menyiarkan PrepareDriveTransaction dan menyatakan dalam Metadata transaksi ukuran drive yang diinginkan dan jumlah replikasi. Setiap Replikator yang ditetapkan ke Drive sama dengan satu replikasi. Oleh karena itu, jika Pemilik Drive memerlukan 100 replikasi untuk data penting atau distribusi massal, 100 Replikator akan ditetapkan ke Drive.

Pemilik Drive perlu memastikan Unit Penyimpanan yang memadai tersedia di akun Drive untuk menjalankan permintaan. Jika Unit Penyimpanan tidak mencukupi, Pemilik Drive dapat memposting Transaksi StoragePayment untuk mengisi ulang akun. Ukuran Drive harus cukup besar untuk memungkinkan pengembalian data. Misalnya, jika Pemilik Drive ingin menyimpan file 1 GB, ia harus mengalokasikan ruang penyimpanan 2 GB.

Validator, mendengarkan blockchain untuk memicu transaksi, mengambil permintaan pembuatan Drive dari Pemilik Drive dan menetapkan Replikator dengan ruang penyimpanan yang cukup ke Drive. Setelah JoinToDriveEvent, Replicator mulai mendengarkan semua pemicu untuk Drive yang sesuai.

Secara default, semua data Drive tersedia untuk umum bagi pengguna platform Sirius. Untuk mencegah hal ini, Pemilik Drive dapat memilih untuk membatasi pembukaan Saluran Unduhan dan mengenkripsi semua file di sisi klien.

Modifikasi Drive

Langkah-langkah modifikasi:

saya. Inisiasi Modifikasi
Untuk memulai modifikasi Drive, Pemilik Drive harus terlebih dahulu memilih opsi perintah yang harus dilakukan oleh Replikator dari Daftar Tindakan:

1. Modifikasi berkas.
2. Hapus berkas.
3. Ganti nama file.
4. Buat folder.
5. Hapus folder.
6. Ganti nama folder.

Setelah item Daftar Tindakan dipilih, Pemilik Drive perlu memposting DataModificationTransaction yang berisi Informasi Unduhan Konten (CDI) pada Daftar Tindakan dan file yang akan dimodifikasi Pemilik Drive membayar untuk mengunggah file yang dimodifikasi ke Replikator. Jumlah pembayaran sama dengan ukuran data yang diunggah dikalikan jumlah ulangan. Jumlah ini dikunci oleh Validator saat Pemilik Drive meminta modifikasi.

Pada titik ini, perangkat lunak Pemilik Drive harus mencegah Pemilik Drive menghapus file yang akan diunduh oleh Replicator hingga blockchain mengonfirmasi DataModificationApprovalTransaction berikutnya yang diposting oleh Replicator.

Jika Pemilik Drive ingin membatalkan modifikasi sebelum DataModificationApprovalTransaction dikonfirmasi, Pemilik Drive harus memposting DataModificationCancelTransaction. Jika dibatalkan, Replikator kemudian akan menolak DataModificationTransaction dan menghapusnya dari Antrean Modifikasi Drive. Pemilik Drive masih harus membayar Replikator yang telah menjalankan modifikasi dan perlu mengembalikan perubahan.

Antrian Modifikasi
Setelah blockchain mengonfirmasi DataModificationTransaction, Replicator menambahkan transaksi ke Antrean Modifikasi Drive. Setelah transaksi mencapai gilirannya dalam antrian, Replikator mengunduh modifikasi data yang diperlukan yang diminta oleh Pemilik Drive yang tercantum dalam Daftar Tindakan dan CDI dan menjalankan permintaan modifikasi.

aku aku aku. Modifikasi Sandbox
Replicator pertama-tama mengunduh semua file yang diperlukan dan menjalankan tindakan yang diminta di Sandbox lokal masing-masing (area penyimpanan sementara atau staging yang akan dikonfigurasikan dengan sengaja) untuk menguji modifikasi.

Jika modifikasi Sandbox berhasil, Replicator memposting DataModificationApprovalTransaction dan menerapkan semua perubahan dalam status langsung (non-Sandbox) segera setelah jaringan mengonfirmasi transaksi dan mencatat jejak Status Drive baru di blockchain.

Jika modifikasi Sandbox gagal, Replikator mengirim jejak Status Drive sebelumnya ke blockchain. Replikator masih menerima pembayaran untuk pekerjaan yang dilakukan.

Modifikasi kotak pasir gagal jika:

• Ukuran data yang diunduh melebihi ukuran yang dinyatakan dalam
• Transaksi Modifikasi Data.
• Data yang diunduh tidak berisi Daftar Tindakan.
• Daftar Tindakan rusak atau berisi tindakan yang tidak valid.
• Terjadi kesalahan saat berinteraksi dengan Sistem File.
• Ukuran Drive setelah menerapkan Daftar Tindakan melebihi ukuran Drive yang dipesan.

Replikator menghapus Sandbox mereka dari file apa pun jika:

Replikator menerapkan modifikasi ke Status Drive.

Modifikasi DataBatalkanTransaksi.
aku aku aku. Replikator merekam modifikasi data yang gagal di blockchain.

Persetujuan Modifikasi
Jika setidaknya plus 1 Replicator mencapai konsensus tentang struktur file baru dan hash file terkait, yang bertindak sebagai sidik jari unik untuk identifikasi, Replicator menandatangani Multi-signature DataModificationApprovalTransaction dan menerapkan modifikasi ke Drive State yang baru.

Replikator yang terlambat menandatangani grup terbaru Multi-signature DataModificationApprovalTransaction harus mengejar ketinggalan dengan memposting DataModificationSingleApprovalTransaction dan menyinkronkan penyimpanannya. Untuk efisiensi, Replicator dapat menyinkronkan dengan mengunduh data yang dimodifikasi dari Replicator lain dan Pemilik Drive. Persetujuan tunggal Replicator dibayar sama seperti Replikator lain untuk pekerjaan yang dilakukan, kecuali mereka harus menutupi biaya transaksi.

Unduh Saluran
Unduh langkah-langkah:

saya. Buka Saluran Unduh
Konsumen menempatkan file di jaringan menggunakan CDI file. Konsumen membayar di muka Unit Streaming melalui DownloadTransaction untuk membuka Saluran Unduhan dengan Drive file. Jumlah Unit Streaming yang disetorkan sama dengan ukuran unduhan data yang tersedia untuk Konsumen. Konsumen juga membayar di muka XPX untuk membayar

transaksi yang dilakukan oleh Replikator. Konsumen dapat melakukan top-up pembayaran di muka dengan memposting DownloadTransactions lebih lanjut.

Lakukan pembayaran
Validator mengunci Unit Streaming prabayar Konsumen di akun escrow. Setelah setiap unduhan yang berhasil dengan ukuran data 1 MB, Konsumen menandatangani tanda terima off-chain untuk pekerjaan yang dilakukan dan mengirimkan salinan ke masing-masing Replikator Drive. Setiap Replicator juga mengirimkan semua Replicator lain Receipts off-chain untuk memastikan sinkronisasi.

Replikator memverifikasi bahwa Tanda Terima:

• secara kumulatif mencerminkan jumlah yang diunduh, diberikan atau diambil beberapa MB (Konsumen dapat mengunduh hingga 1 MB secara gratis);
• bukan duplikat;
• adalah untuk unduhan yang dikonsumsi dan bukan layanan di masa mendatang; dan
• tidak melebihi setoran prabayar Konsumen.

Replikator mengabaikan Tanda Terima yang tidak valid. Jika Tanda Terima melebihi setoran prabayar, Replikator berhenti mengunggah data dan hanya memulai kembali setelah Konsumen mengisi ulang akunnya.

Replikator kemudian menggunakan Tanda Terima yang valid untuk membentuk opini kolektif. Jika setidaknya ditambah 1 Replikator menyetujui pekerjaan yang dilakukan, memberi atau menerima beberapa MB, mereka memposting a
Unduh Multi-tanda tanganPersetujuanTransaksi. Validator membayar Replikator nilai median dari Opini di akhir setiap periode penagihan unduhan 24 jam.

Untuk setiap Saluran Unduhan, Replikator hanya menyimpan Tanda Terima terakhir sehingga ruang penyimpanan yang digunakan oleh Tanda Terima tetap minimal. Replikator dapat menghapus semua Tanda Terima setelah Saluran Unduhan ditutup.

Tutup Saluran Unduh
Konsumen dapat menutup Saluran Unduhan dengan memposting FinishDownloadTransaction. Replikator mencapai konsensus tentang pembayaran apa pun yang terutang dan memposting hasilnya melalui Multi-signature DownloadApprovalTransaction. Validator mengeluarkan pembayaran kepada Replikator dan mengembalikan dana prabayar yang tidak digunakan kepada Konsumen.

Penutupan Drive
Pemilik Drive memposting DriveClosureTransaction untuk menutup Drive. Misalkan transaksi mengakhiri periode penagihan Drive saat ini sebelum waktunya (kurang dari empat minggu). Dalam hal ini, Replicator memposting DownloadApprovalTransactions yang luar biasa untuk meminta pembayaran oleh Validator untuk layanan yang diberikan hingga saat itu. Validator mengembalikan kepada Pemilik Drive Unit Penyimpanan yang tidak digunakan dari akun Drive dan menetapkan Replikator ke Drive baru.

Jika Unit Penyimpanan di akun Drive habis, Validator akan menutup Drive. Tidak ada masa tenggang karena Pemilik Drive tidak dapat mengharapkan peserta jaringan yang terdesentralisasi untuk bekerja secara gratis. Perangkat lunak Pemilik Drive dapat memberikan peringatan yang memadai saat dana prabayar hampir habis dan perlu diisi ulang.

Verifikasi Replikator
Replicator perlu menyimpan modifikasi terbaru untuk memiliki Drive State terbaru dengan menandatangani Multi-signature DataModificationApprovalTransaction, atau jika terlewat, DataModificationSingleApprovalTransaction diikuti dengan sinkronisasi.

Protokol verifikasi penyimpanan menemukan, menghukum, dan menghapus Replikator yang tidak sinkron. Verifikasi terjadi secara acak, beberapa kali sehari, di mana Replikator saling mengirim bukti memiliki Status Drive terbaru. Replicator kemudian memposting pendapat mereka tentang hasil verifikasi melalui DriveVerificationTransaction multi-tanda tangan yang membutuhkan setidaknya plus 1 Replicator untuk menandatangani.

Validator mengidentifikasi dari DriveVerificationTransactions Replikator apa pun yang tidak berpartisipasi dalam proses verifikasi selama lebih dari dua hari, menghapusnya dari daftar, dan menyita deposit mereka sebagai hukuman untuk mencegah kegagalan kinerja.

Pengambilan Keputusan Kolektif
Drive Replicator memberikan pendapat kolektif mereka dalam Metadata transaksi Multi-signature, di mana setidaknya plus 1 Replicator diperlukan untuk mencapai konsensus dan menandatangani transaksi. Validator yang mendengarkan blockchain memproses transaksi. Ini menghitung median dari semua pendapat untuk membentuk keputusan akhir (misalnya, pembayaran yang akan dilakukan atau menghapus Replikator dari Drive).

Transaksi opini multi-tanda tangan meliputi:

• UnduhPersetujuanTransaksi.
• DataModificationApprovalTransaction.
• DriveVerificationTransaction.

Penetapan Prioritas Replikator

ProximaX mengembangkan algoritme untuk memprioritaskan penetapan Replikator ke Drive oleh Validator. Segera setelah Harvester menambahkan semua transaksi ke blok dan menambahkannya ke blockchain, Validator membentuk daftar Drive dengan Replicator yang hilang. Karena ada periode di mana Validator tidak dapat mengisi semua lowongan Replicator di Drive karena jumlah Replicator yang rendah di jaringan, algoritme membuat antrean prioritas yang memprioritaskan Drive dengan kurang dari empat Replicator di mana data paling rentan. Validator akan memposisikan Drive dengan tingkat prioritas yang sama dalam antrian dengan cara yang deterministik.

Distribusi Konten Massal
Drive dengan banyak Replikator (mis., 100) untuk data penting atau distribusi konten massal akan berfungsi secara tidak efisien, karena terlalu banyak Replikator yang perlu berkomunikasi satu sama lain dan menandatangani transaksi Multi-tanda tangan.

Protokol penyimpanan mengatasi ketidakefisienan ini dengan membagi Replicator menjadi sub-grup yang masing-masing tidak lebih dari 20 Replikator. Di sini, Replikator mengunduh data, melakukan verifikasi, dan mengungkapkan pendapat dalam sub-grup mereka.

Unggah data ke Konsumen menjadi lebih efisien karena hanya satu Saluran Unduhan sub-grup yang dipilih secara acak yang dibuat.

Pribadi
Kunci publik dapat dilihat oleh publik, yang berarti siapa pun dapat melacak aktivitas jaringan. Dimungkinkan untuk mengambil pendekatan seperti VPN untuk memberikan opsi akses anonim ke layanan Sirius Storage dan Sirius Stream.

Ilustrasi desain konseptual di bawah ini menunjukkan bagaimana Replikator dapat membentuk Drive Virtual off-chain dengan memori yang dialokasikan nol dan terhubung ke Saluran Unduhan atas nama Konsumen, menghapus interaksi langsung Konsumen dengan Drive yang menyebabkan terbukanya kunci publik mereka. Karena Drive Virtual hanya berfungsi sebagai saluran untuk mengunduh data, tidak diperlukan ruang penyimpanan. Drive Virtual berada di luar rantai sehingga tidak ada catatan transaksi blockchain antara Konsumen dan Replikator Drive Virtual.

Drive Virtual berinteraksi dengan Drive lain atas nama Konsumen seperti yang dilakukan Konsumen dengan membuka Saluran Unduhan, melakukan deposit untuk penggunaan layanan, dan mengirimkan Tanda Terima ke Replikator atau Distributor Drive (lihat bab berikutnya tentang Sirius Stream).

Konsumen harus membayar ekstra untuk layanan tersebut, karena ada kebutuhan untuk membayar Replikator Drive Virtual untuk pekerjaan yang dilakukan dan menutupi pembayaran yang mereka lakukan untuk mendapatkan layanan.

Sponsor
Sponsor, seperti pengiklan, dapat mensponsori layanan penyimpanan dan streaming untuk menjadikannya gratis bagi Konsumen dan Penerima (lihat bab berikutnya tentang Sirius Stream).

Sponsor membuat Saluran Unduhan dengan memposting Transaksi Unduhan dan dapat membuatnya tersedia untuk Konsumen atau Penerima yang dipilih dengan memasukkan kunci publik mereka dalam transaksi atau menyetel nilainya ke nol (0) untuk memungkinkan siapa saja melihat streaming.

Sponsor dapat menutup saluran dengan memposting FinishDownloadTransaction, setelah itu Validator mengembalikan dana prabayar yang tidak digunakan.

Onboarding & Offboarding Replikator

Orientasi
Untuk menyumbangkan ruang penyimpanan ke jaringan, Replicator perlu memposting ReplicatorOnboardingTransaction untuk memicu JoinToDriveEvent dan membuktikan ruang penyimpanan yang tersedia dengan menyetorkan Unit Layanan jaminan yang dikonversi dari XPX oleh Validator menggunakan Sirius DEX.

Validator menetapkan Replikator ke Drive. Setelah itu, Replicator mendengarkan semua transaksi masuk (pemicu) milik Drive masing-masing. Validator kemudian mendaftarkan ruang penyimpanan yang ditetapkan oleh Replicator untuk Drive sebagai “sedang digunakan”.

Offboarding
Untuk keluar dari Drive, Replicator perlu memposting ReplicatorOffboardingTransaction dan menyatakan Kunci Publik Drive, memicu LeaveDriveEvent. Saat offboarding, Validator mengembalikan ke Replicator semua Unit Penyimpanan yang disimpannya. Namun, Replicator akan kehilangan Unit Streaming untuk membayar pekerjaan upload data dari Replicator baru yang bergabung dengan Drive.

Harvester tidak akan menambahkan ReplicatorOffboardingTransaction ke blok dan membiarkan Replicator pergi jika itu berarti Drive akan berakhir dengan kurang dari empat Replicator. Misalkan Replicator tetap memutuskan untuk berhenti melakukan perannya sebagai Replicator. Dalam hal ini, proses verifikasi Replicator akan mengidentifikasi ini, dan Validator akan meninggalkan Replicator dan menyita depositnya (lihat 4.6. di atas).

Pemilik Drive dapat memposting ReplicatorOffboardingByDriveOwnerTransaction untuk menghapus Replicator berperforma rendah (mis., mengunggah data secara perlahan) jika setidaknya empat Replicator tetap ditetapkan ke Drive untuk memastikan ketersediaan data yang memadai. Replicator dibayar dengan jumlah prorata untuk periode penagihan dan depositnya dikembalikan. Pemilik Drive harus memberikan kompensasi kepada jaringan untuk pekerjaan yang dilakukan untuk mengganti Replicator.

Lokasi Replikator Daftar yang Diizinkan & Daftar Blok
Selama pembuatan Drive, Pemilik Drive dapat menyertakan dalam PrepareDriveTransaction:

1. Daftar Replikator yang Diizinkan: Negara tempat Replikator yang ditugaskan dapat ditemukan.
2. Daftar Blokir Replikator: Negara tempat Replikator yang ditugaskan tidak dapat ditemukan.

Saat Validator menetapkan Replikator ke Drive, mereka menetapkan Replikator sesuai dengan permintaan lokasi Pemilik Drive.

Replicator menyatakan lokasi mereka selama ReplicatorOnboardingTransaction.

Validator mengelola aliran token berdasarkan transaksi masuk dan melakukan pembayaran. Pemilik Drive hanya membayar dalam XPX, dan Replikator hanya dibayar dalam XPX. Menurut nilai tukar terbaru Sirius DEX, Validator membuat semua konversi Unit Layanan yang diperlukan atas nama Pemilik Drive, Replikator, dan Konsumen.

Sekali per periode penagihan (setiap empat minggu untuk Pemilik Drive dan setiap 24 jam untuk Konsumen), Validator melakukan pembayaran XPX ke Replikator untuk pekerjaan yang dilakukan dengan mengonversi Unit Penyimpanan dan Unit Streaming yang terkunci di akun Drive dan akun escrow Konsumen.

Replicator hanya menerima pembayaran untuk periode yang disimpannya dalam Status Drive terbaru. Validator akan membayar Replicator sejumlah prorata jika ada periode di mana protokol mengonfirmasi bahwa Replikator tidak berfungsi (tidak menyimpan Status Drive terbaru). Validator mengidentifikasi Replicator yang tidak berkinerja melalui DriveVerificationTransactions dan DataModificationSingleAprovalTransactions berlebihan yang diposting di blockchain. Jika Replicator tidak membuktikan bahwa ia memiliki Drive State terbaru selama lebih dari dua hari, ia kehilangan depositnya

Pembuatan Streaming Langsung
Pengirim harus melakukan tindakan berikut untuk membuat aliran:

1. Jika belum selesai, pesan Storage Drive dengan ukuran yang dibutuhkan.
2. Lakukan pembayaran di muka untuk streaming (Streaming Units) dengan memposting StreamPaymentTransaction. Pengirim dapat memposting transaksi yang sama selama streaming langsung untuk meningkatkan jumlah prabayar.
3. Posting StreamStartTransaction untuk memulai streaming. Transaksi awal menyatakan ukuran aliran yang diharapkan, yang harus sesuai dengan jumlah prabayar.

StreamStartTransaction memicu hal berikut:

1. Validator mengunci pembayaran di muka di akun Drive untuk membayar pekerjaan Distributor setelah streaming berakhir.
2. Replikator menambahkan permintaan ke Antrean Modifikasi Drive, karena Replikator memproses aliran sebagai jenis modifikasi data.
3. Replikator memulai peran Distributor dan mengirimkan aliran ketika modifikasi data mencapai gilirannya dalam antrian.

Secara default, semua streaming langsung tersedia untuk umum bagi pengguna platform Sirius. Untuk mencegah hal ini, Pemilik Drive dapat memilih untuk membatasi pembukaan Saluran Download dan mengenkripsi aliran sehingga hanya pengguna yang diizinkan yang dapat menggunakan aliran ini.

Transmisi Streaming Langsung

Saat StreamStartTransaction berada di baris berikutnya dalam Antrean Modifikasi, hal berikut terjadi:

saya. Pembuatan Daftar Putar oleh Pengirim
Segmen aliran dimasukkan secara kronologis ke dalam daftar putar oleh perangkat lunak Pengirim sehingga Penerima Aliran (Penerima) dapat melihat segmen sebagai aliran lengkap. Daftar putar berisi informasi tentang nomor identifikasi setiap segmen aliran, urutan berurutan, dan ukuran data. Pengirim menandatangani setiap daftar putar dengan kunci pribadinya sehingga Distributor dan Penerima dapat memverifikasi asalnya.

Unduh oleh Distributor
Distributor mulai mengunduh segmen media setelah mereka memverifikasi bahwa (a) Pengirim telah menandatangani setiap daftar putar dan (b) ukuran unduhan yang diharapkan yang disebutkan dalam StreamStartTransaction tidak melebihi jumlah prabayar Pengirim. Distributor mengunduh segmen streaming dalam susunan kronologis yang benar, mencocokkan nomor urut setiap segmen dengan daftar putar yang sesuai.

Perekaman Loop untuk Streaming Tanpa Jeda
Distributor menyimpan setiap segmen sebagai loop streaming di sandbox masing-masing untuk memungkinkan streaming berkelanjutan. Jika segmen yang masuk melebihi ruang sandbox yang tersedia yang sama dengan total ukuran Drive, Distributor menghapus segmen terlama dan menyimpan yang terbaru ke loop streaming.

Unduh oleh Penerima
Penerima menemukan aliran di jaringan menggunakan Informasi Distribusi Konten (CDI) dan memposting DownloadTransaction untuk melakukan setoran prabayar untuk membuka Saluran Unduhan untuk melihat aliran. Penerima dapat menambah deposit dengan memposting DownloadTransaction lain kapan saja selama streaming jika dana prabayar hampir habis.

Penerima mulai mengunduh segmen streaming dalam pengaturan kronologis yang benar, termasuk segmen yang direkam, untuk membuat zona penyangga untuk streaming langsung bebas lag. Default zona penyangga jaringan adalah 60 segmen, yang berarti sekitar 60 detik. Perangkat lunak Penerima dapat menyesuaikan default zona penyangga.

Komunikasi antar Node
Distributor memberi tahu Penerima tentang segmen baru yang akan diunggah. Distributor memberi tahu Pengirim setiap segmen yang berhasil diunduh.

Penerima mengirimkan Tanda Terima ke Distributor untuk setiap 1 MB yang dialirkan. Dengan menggunakan protokol komunikasi Sirius Storage Receipt yang sama, Distributor memverifikasi bahwa Receipt:

sebuah. secara kumulatif mencerminkan jumlah yang diunduh, diberikan atau diambil beberapa MB (Penerima dapat mengunduh hingga 1 MB secara gratis);

1. bukan duplikat;
2. adalah untuk unduhan yang dikonsumsi dan bukan layanan di masa mendatang; dan
3. tidak melebihi setoran prabayar Penerima.

Jika Resi tidak lolos proses verifikasi, maka Download Channel ditutup. Jika Tanda Terima lolos verifikasi, pada akhir periode penagihan 24 jam, Distributor membentuk opini kolektif (setidaknya plus 1 Distributor) atas pekerjaan yang dilakukan dengan menggunakan Tanda Terima dan memasukkan hasilnya dalam Transaksi DownloadApproval. Validator kemudian membayar Distributor nilai median opini menggunakan deposit Penerima dan mengembalikan dana yang tidak terpakai kepada Penerima.

Seperti biasa, Distributor yang belum menandatangani persetujuan Multi-signature mengejar ketinggalan dengan memposting Transaksi DataModificationSingleApproval untuk modifikasi terbaru, seperti di Sirius Storage. Mereka kemudian menyinkronkan data Drive dengan Distributor lain atau Pemilik Drive.

Tutup Saluran Unduh
Penerima dapat menutup Saluran Unduhan sebelum streaming berakhir dengan memposting FinishDownloadTransaction. Para Distributor mencapai konsensus tentang setiap pembayaran yang terutang (setidaknya ditambah 1 Distributor) dan memposting hasilnya melalui a
Multi-signature DownloadApprovalTransaction. Validator mengeluarkan pembayaran kepada Distributor dan mengembalikan dana prabayar yang tidak terpakai kepada Penerima.

Akhiri Streaming Langsung
Pengirim memposting StreamFinishTransaction untuk mengakhiri streaming langsung. Metadata transaksi berisi informasi tentang daftar putar dan segmen yang di-streaming serta petunjuk tentang apakah Replikator diperlukan untuk menyimpannya ke Drive untuk streaming penyimpanan (streaming sesuai permintaan).

Transaksi memicu hal berikut:

Verifikasi
Distributor memverifikasi apakah struktur streaming (daftar putar dan segmen media) yang dinyatakan oleh Pengirim konsisten dengan salinan lokal yang disimpan oleh masing-masing Distributor selama streaming langsung. Verifikasi memastikan bahwa Pengirim tidak dapat menipu sistem dan membayar lebih sedikit dengan menyatakan ukuran streaming yang lebih kecil.

Persetujuan
Distributor secara kolektif memverifikasi dan mencapai konsensus (setidaknya ditambah 1 Distributor) bahwa:

sebuah. Pengirim telah menyatakan dengan benar ukuran aliran total (memberi atau menerima parameter default); dan pada pembayaran yang akan diterima untuk pekerjaan yang dilakukan.

Distributor menandatangani Multi-signature DataModificationApprovalTransaction dan menyimpan ke Drive semua data yang diminta untuk streaming sesuai permintaan. Validator kemudian membayar Distributor untuk pekerjaan yang dilakukan dan mengembalikan dana streaming terkunci yang tidak digunakan kepada Pengirim.

Penolakan
Jika Distributor mengidentifikasi ketidakkonsistenan dengan pernyataan Pengirim, mereka tidak menandatangani transaksi persetujuan modifikasi, dan Drive dibuat tidak tersedia untuk Pengirim. Drive dapat tersedia kembali setelah perangkat lunak Pengirim memposting DataModificationCancelTransaction.

Siaran Langsung Massal

Seperti dijelaskan di bagian 4.9., pembentukan sub-grup sangat penting untuk menghindari kemacetan layanan yang disebabkan oleh sekelompok besar Distributor yang harus berkomunikasi satu sama lain.

Dengan sub-grup Distributor, streaming langsung terdesentralisasi menjadi lebih efisien. Penerima hanya mengunduh streaming dari satu sub-grup Distributor yang dipilih secara acak. Distributor hanya bertukar daftar putar, segmen streaming, dan Tanda Terima dalam sub-grup mereka.

Namun, bahkan pembentukan sub-grup mungkin tidak mengatasi permintaan bandwidth yang signifikan dari ribuan Penerima. Jaringan memecahkan masalah ini dengan mengizinkan Penerima untuk menyumbangkan bandwidth mereka dan menjadi Redistributor hilir, di mana Penerima mengumpulkan dan mengirimkan Tanda Terima untuk pekerjaan yang dilakukan dan mendapatkan pembayaran dari Validator.

Bagaimana itu bekerja:

saya. Redistributor Mengumpulkan Tanda Terima & Membayar Biaya
Penerima mengirimkan Tanda Terima ke Redistributor untuk setiap 1 MB yang diunduh dari Redistributor, seperti yang akan dilakukan dengan Distributor. Demikian juga, Redistributor memeriksa bahwa Tanda Terima:

• secara kumulatif mencerminkan jumlah yang diunduh, diberikan atau diambil beberapa MB (Penerima dapat mengunduh hingga 1 MB secara gratis);
• bukan duplikat; dan
• adalah untuk unduhan yang dikonsumsi dan bukan layanan di masa mendatang.

Sebelum akhir periode penagihan 24 jam, Redistributor memposting IncludeToPaymentTransaction untuk menambahkan klaim hadiahnya ke DownloadApprovalTransaction yang diposting oleh Distributor. The IncludeToPaymentTransaction memerlukan tambahan sedikit biaya yang dibayarkan oleh Redistributor untuk membuat spam jaringan atau mengklaim hadiah kecil (kurang dari biaya layanan) oleh Redistributor menjadi tidak menguntungkan.

Distributor Proses Kwitansi & Formulir Konsensus
Jika Tanda Terima lolos verifikasi Redistributor, Redistributor mengirimkan Tanda Terima ke Distributor. Distributor juga melakukan verifikasi yang sama dengan Redistributor dan memastikan bahwa Tanda Terima tidak melebihi setoran prabayar Penerima.

The IncludeToPaymentTransaction memicu Distributor untuk membentuk opini tentang hadiah Redistributor dan memasukkannya ke dalam DownloadApprovalTransaction.

aku aku aku. Validator Memverifikasi Biaya & Mengeluarkan Hadiah
Imbalan yang dikeluarkan oleh Validator adalah median dari semua Pendapat Distributor. Sebelum melakukan pembayaran ke Redistributor, Validator memeriksa apakah Redistributor memposting IncludeToPaymentTransaction dan melampirkan biaya yang diperlukan.

Streaming Tokenomics

Pembuatan Kontrak
Supercontract pada dasarnya adalah “kotak fungsi” yang dapat Anda buat dan program untuk memicu pelaksanaan tindakan tertentu setelah terjadinya beberapa peristiwa yang disepakati.

Kreator dapat menggunakan SDK yang tersedia dalam beberapa bahasa pengkodean umum (mis., Javascript, Golang, C++, Rust) untuk membuat Supercontract.

Tergantung pada desainnya, Superkontrak berjalan saat dipanggil oleh Penelepon atau secara otomatis saat dipicu oleh terjadinya suatu peristiwa. Peristiwa ini dapat berupa tanggal (misalnya, ketika bunga jatuh tempo) atau terjadinya tindakan yang disepakati (misalnya, saat pengiriman atau hasil), atau umpan oracle yang menandakan tindakan pemicu (misalnya, nilai harga), atau hanya pada transaksi dikirim ke rekening tertentu.

Penempatan Kontrak
Langkah-langkah penerapan:

Permintaan Penerapan
Untuk menerapkan Superkontrak, Kreator membuat Drive penyimpanan dengan ukuran yang memadai untuk menampung kodenya. Pada titik proses ini, Kreator adalah Pemilik Drive.

Kreator kemudian memposting DeployTransaction, yang memicu Replikator Drive untuk menambahkan penerapan ke Antrean Modifikasi penyimpanan. Ketika transaksi berikutnya sejalan, berikut ini terjadi:

• Pembuatan pengenal untuk Supercontract bernama Supercontract Public Key (sama dengan hash dari Public Key Drive) sehingga Validator dapat mengaitkan Drive dengan Supercontract dan mengabaikan transaksi modifikasi dan penutupan Drive untuk sementara.
• Replikator menjalankan Supercontract Installer, sebuah fungsi WebAssembly (Wasm), untuk memverifikasi bahwa kode Supercontract dapat dijalankan.
• Jika ada, Replicator memeriksa validitas file auto-run yang secara otomatis menjalankan Supercontract setelah terjadinya suatu peristiwa.

Penerapan yang Berhasil
Jika Replicator tidak menemukan masalah dengan Supercontract, Replicator akan memberi tahu jaringan tentang hasilnya melalui EndDeployTransaction yang memicu hal berikut:

• Replikator mengunggah kode Supercontract ke Drive.
• Replikator menjadi Pelaksana Superkontrak dan mulai mendengarkan semua pemicu transaksi terkait.
• Replicator menyimpan file peluncuran otomatis apa pun di memori mereka dan mendengarkan pemicu transaksi peluncuran otomatis.
• Validator mengaitkan transaksi Drive secara permanen dengan Supercontract dan mengabaikan DataModificationTransactions dan DriveClosureTransactions.
• Superkontrak hanya akan berhenti bekerja jika Unit Penyimpanannya habis, yang dapat diisi ulang oleh pengguna jaringan mana pun. Fitur ini memungkinkan Supercontract untuk berjalan terus-menerus jika pihak yang menyebarkan tidak ada lagi atau tidak lagi tertarik untuk mempertahankan Supercontract.

Deployment Tidak Berhasil
Jika EndDeployTransaction memberi tahu jaringan tentang kegagalan penerapan apa pun, maka hal berikut akan terjadi:

• Replikator menghentikan penerapan dan menjalankan Drive dalam mode standar untuk penyimpanan saja.
• Validator tidak lagi mengaitkan Superkontrak dengan Drive.
• Validator mengembalikan dana yang tidak terpakai ke Pemilik Drive.
• Pemilik Drive dapat memperbaiki kegagalan atau menutup Drive.

Eksekusi Kontrak
Langkah-langkah eksekusi:

saya. Mulai Eksekusi
Setiap pengguna dapat menjadi Penelepon Superkontrak. Seorang Penelepon dapat:

1. Jalankan fungsi Superkontrak.
2. Jelajahi hasil eksekusi dari Drive melalui Saluran Unduhan.
3. Jelajahi apa yang disebut Pelaksana telah berjalan dan statusnya (berhasil atau gagal).
4. Jelajahi berapa banyak Supercontract Service Units (SC Units) yang telah dibelanjakan oleh Penelepon.
5. Dukung Drive Supercontract sebagai sponsor dengan mengisi akunnya dengan Storage Unit (unit SO).

Penelepon membayar Unit SC untuk mengeksekusi Supercontract and Streaming Units (SM Units) jika eksekusi mengharuskan Pelaksana untuk mengunduh data ke mesin virtual dari Internet.

Penelepon menjalankan fungsi Superkontrak tertentu dengan memposting
StartExecuteTransaction yang berisi informasi berikut:

• Pengenal superkontrak.
• Nama fungsi yang dipanggil.
• Parameter masukan untuk fungsi ini.
• Jenis dan jumlah unit yang disediakan untuk melakukan panggilan.

Antrian Eksekusi
Pelaksana membuat Antrian Eksekusi untuk setiap Supercontract, di mana mereka menempatkan semua panggilan yang diterima, baik manual atau otomatis, sesuai dengan urutan yang muncul di blockchain.

Untuk memastikan Antrian Eksekusi tidak memperlambat eksekusi, terutama untuk Supercontracts populer, eksekusi terjadi dalam batch berurutan. Pelaksana menambahkan semua StartExecuteTransactions di blok blockchain baru sebagai batch dalam antrian.

Jika EndExecuteTransaction diterima, Pelaksana menghapus permintaan panggilan yang sesuai dari kumpulannya dalam antrian.

Menjalankan Kode
Ketika sebuah batch berada di baris berikutnya dalam Antrian Eksekusi, Pelaksana menjalankan setiap panggilan dalam batch di kotak pasir masing-masing untuk membuat hasil eksekusi batch.

Setiap Pelaksana menjalankan kode Supercontract secara dinamis menggunakan mesin virtual yang mampu Wasm. Eksekusi panggilan Supercontract sedang memproses fungsi tertentu dari kode Wasm di mesin virtual. Kode Wasm tidak dapat langsung berinteraksi dengan lingkungan eksternal, seperti Internet, tanpa menggunakan mesin virtual yang mengaktifkan fungsi panggilan kontrak.

Eksekusi kode Supercontract harus selalu mengikuti urutan yang ditetapkan, artinya setiap Pelaksana harus memberikan hasil yang sama. Jika ada eksekusi yang salah, rollback terjadi menggunakan data kotak pasir yang disimpan untuk memperbaiki kesalahan.

Ada beberapa alasan mengapa eksekusi Supercontract bisa gagal:

1. File Wasm rusak atau tidak ada.
2. Unit SC tidak cukup untuk pelaksanaan kontrak.
3. Tidak ada cukup ruang di Drive Supercontract untuk menyimpan file karena Unit SO di akun Drive tidak mencukupi.
4. Unit SM tidak cukup untuk mengunduh data dari Internet jika diperlukan.

Pengambilan Keputusan Kolektif
Setelah setidaknya plus 1 Pelaksana mencapai konsensus melalui protokol pengambilan keputusan kelompok pada hasil eksekusi batch, mereka menandatangani Multi-signature EndBatchExecuteTransaction yang terdiri dari opini kolektif terkait apakah eksekusi batch berhasil atau tidak.

Pelaksana yang kehilangan penandatanganan transaksi Multi-tanda tangan perlu mengejar ketinggalan dengan menandatangani EndBatchExecuteSingleTransaction atau menyinkronkan dengan Pelaksana lainnya (lihat bagian 6.6.).

Jika protokol tidak mencapai setidaknya plus 1 konsensus karena alasan seperti Pelaksana sedang offline, waktu habis batch, dan Pelaksana menandatangani EndBatchExecuteTransaction untuk mencatat kegagalan. Pemilik Superkontrak menetapkan batas waktu pengambilan keputusan selama pembuatan Superkontrak.

Hasil Eksekusi

EndBatchExecuteTransaction berisi:

• Referensi ke transaksi yang memulai panggilan dalam batch.
• Pendapat pelaksana tentang apakah eksekusi batch berhasil atau gagal.
• Hash status baru Drive.
• Data yang dibutuhkan untuk penghargaan jaringan untuk pekerjaan yang dilakukan.

Eksekusi superkontrak membuat perubahan pada Status Drive Superkontrak (penambahan, penghapusan, modifikasi).

Eksekusi Batch yang Dapat Dikonfigurasi

Untuk efisiensi jaringan, Supercontract Executors memposting EndBatchExecuteTransaction untuk merekam hasil eksekusi sejumlah panggilan daripada setiap panggilan individu. Batch terdiri dari semua panggilan yang terkandung dalam blok blockchain. Kekurangannya adalah jika satu panggilan dalam batch gagal, Pelaksana menandai seluruh batch sebagai gagal – “satu apel yang buruk dapat merusak kelompok itu.”

Pemilik Supercontract dapat memecahkan masalah potensial ini dengan menetapkan sebelumnya pada pembuatan Supercontract berapa banyak panggilan eksekusi dalam blok blockchain membentuk batch:

1. Semua panggilan dalam satu blok:
   Ini adalah default jaringan, cocok untuk Superkontrak stabil dan dasar dalam penggunaan reguler yang jarang menghasilkan kegagalan eksekusi.
2. Beberapa panggilan dalam satu blok:
   Jumlah panggilan maksimum yang ditentukan dari sebuah batch untuk mengurangi kemungkinan kegagalan eksekusi batch.
3. Satu panggilan pada satu waktu:
   Di sini, Pelaksana perlu memposting EndBatchExecuteTransaction untuk setiap panggilan dalam blok blockchain, berguna untuk Supercontracts yang rentan terhadap kegagalan eksekusi seperti yang bergantung pada data unduhan Internet atau Supercontracts yang jarang digunakan oleh Penelepon.

Seorang Penelepon dapat membayar lebih untuk memilih hasil panggilan yang akan direkam di blockchain secara individual dan bukan sebagai kumpulan, mengurangi kemungkinan hasil kegagalan eksekusi.

Pelaksana juga dapat mengubah ukuran batch secara dinamis, mengurangi jumlah panggilan jika batch sebelumnya ditandai sebagai gagal.

Eksekusi Terlambat
Pelaksana yang belum menandatangani EndBatchExecuteTransaction(s) tepat waktu (misalnya, karena offline) memiliki dua opsi untuk mengejar:

1. Jika Pelaksana memperoleh hasil eksekusi yang sama:
   Setelah mengeksekusi setiap batch yang terlewat satu per satu di luar rantai dan mencapai hasil yang sama yang ditunjukkan di EndBatchExecuteTransactions, Pelaksana dapat memposting EndBatchExecutationSingleTransaction. Pelaksana akan menerima hadiah untuk semua batch yang terlewat kecuali yang berumur lebih dari satu jam karena protokol akan menganggap Pelaksana terlalu jauh tertinggal. Pelaksana harus menanggung biaya transaksi untuk satu transaksi.
2. Jika Pelaksana tidak mendapatkan hasil eksekusi yang sama:
   Misalkan Pelaksana tidak menerima hasil yang sama yang ditunjukkan dalam EndBatchExecuteTransactions setelah mengeksekusi setiap batch yang terlewat (misalnya, karena kondisi yang berbeda pada saat eksekusi). Dalam hal ini, Executor perlu menyinkronkan Drive State-nya dengan Executor lainnya. Pelaksana tidak akan menerima hadiah.

Jika Pelaksana secara berturut-turut melewatkan pengambilan keputusan kelompok kolektif dan penandatanganan transaksi Multi-tanda tangan, Validator menghapus Pelaksana yang tidak berkinerja baik dari Drive Supercontract dan menyita depositnya.

Bukti Eksekusi
Pelaksana perlu membuktikan kepada Validator bahwa mereka telah menjalankan Batch Superkontrak melalui protokol ProximaX Proof of Execution (PoEx) yang melindungi jaringan dari Pelaksana yang tidak berkinerja yang mencoba mengklaim hadiah untuk pekerjaan yang tidak dilakukan.

Protokol membuat Pelaksana membuktikan eksekusi Supercontract melalui kriptografi pasangan kunci menggunakan kurva eliptik yang dibuat menggunakan data eksekusi Supercontract.

Pelaksana harus membuktikan eksekusi batch terbaru ke Validator melalui protokol dalam waktu satu jam dari EndBatchExecuteTransactiontion untuk menerima hadiah, mendorong Pelaksana untuk mengeksekusi tepat waktu dan tetap up-to-date.

Eksekusi Kontrak Agregat
Supercontracts dapat menjalankan Supercontracts bersarang atau berjenjang jika berisi parameter panggilan dan dana yang diperlukan untuk dieksekusi, menciptakan Eksekusi Agregat.

Misalnya, Penelepon menjalankan Supercontract #1 dengan StartExecuteTransaction. Pelaksana memproses panggilan ini, merilis ReleasedTransactionsTransaction yang berisi StartExecuteTransaction baru untuk menjalankan Supercontract #2.

Eksekusi Supercontract juga dapat melepaskan transaksi otomatis bawaan, lebih khusus, agregat ReleasedTransactionsTransactions.

Supercontract #1 akan melakukan pembayaran untuk menjalankan Supercontract #2 menggunakan dana tambahan dari Penelepon awal.

Unduh Data dari Drive lain
Pelaksana dapat mengunduh data yang diperlukan untuk menjalankan Supercontract dari Internet dan Drive lain di jaringan.

Pelaksana dapat melakukan sinkronisasi dengan Replikator dan Pelaksana yang telah mengunduh data. Pelaksana menerima pembayaran tambahan untuk menutupi biaya mengunduh data dari Drive lain. Pelaksana berbagi pendapat untuk mencapai konsensus tentang biaya, pekerjaan yang dilakukan, dan kompensasi yang akan diterima.

Penutupan Kontrak
Supercontract berhenti berfungsi setelah akun Drive Supercontract kehabisan Storage Unit (SO Units). Siapa pun dapat mengisi ulang akun Drive Supercontract dengan Unit SO agar Supercontract tetap berjalan.

Kreator tidak dapat menutup Drive Supercontract dengan DriveClosureTransaction karena Validator akan mengabaikan transaksi tersebut. Pencipta juga tidak dapat menutup Supercontract dengan mentransfer Unit SO keluar dari akun Supercontract karena Pencipta tidak memegang kunci pribadi ke akun Drive Supercontract, oleh karena itu, tidak dapat mentransfer dana keluar.

Tetapi Pencipta dapat memasukkan logika lanjutan selama pembuatan Supercontract dalam kode Supercontract untuk memblokir eksekusi fungsi tertentu atau semua. Desainnya dapat mencakup pelaksanaan transaksi Multi-tanda tangan oleh pihak yang disetujui atau pemungutan suara publik untuk menghentikan fungsi tersebut.

Ketika Supercontract ditutup, Executors membatalkan semua eksekusi yang tertunda di Execution Queue kecuali yang pertama, karena Executors sudah mulai mengerjakannya.

ProximaX telah merancang Supercontract sedemikian rupa sehingga Penelepon dapat mengandalkan Supercontracts tanpa khawatir akan ditutup secara sewenang-wenang oleh Pencipta. Oleh karena itu, Pencipta adalah “Pencipta” dan bukan “Pemilik” Superkontrak.

Onboarding & Offboarding Pelaksana
Saat Replicator baru ditetapkan oleh Validator ke Drive Supercontract untuk menjadi Executor, Replicator harus mengikuti langkah-langkah orientasi Sirius Storage Replicator yang diuraikan di atas. Replicator baru pertama-tama menandatangani DataModficationSingleAprovalTransaction untuk melakukan sinkronisasi data. Jika Replicator melewatkan EndBatchExecuteTransaction, Replicator harus menandatangani EndBatchExecuteSingleTransaction untuk mengejar ketertinggalan dengan Executors lainnya. Replicator baru kemudian menjadi Executor untuk Drive Supercontract. Off-boarding mengikuti proses yang sama seperti Sirius Storage.

Tokenomics Superkontrak
Drive Superkontrak memerlukan Unit Penyimpanan (SO Units) agar berfungsi.

Pemanggil membayar Unit Superkontrak (Unit SC) untuk menjalankan Superkontrak dan Unit Streaming (Unit SM) jika eksekusi memerlukan pengunduhan data ke mesin virtual melalui Internet atau Drive lain di jaringan.

1 Unit Layanan SC sesuai dengan 1 miliar kode operasi Supercontract (opcode), sesuai dengan satu centang di mesin virtual WebAssembly.

Menurut nilai tukar terbaru, Validator menukar Unit SC dan SM atas nama Penelepon menggunakan Sirius DEX.

Saat Penelepon memposting StartExecuteTransaction, Validator mengunci jumlah Unit SC dan SM yang diperlukan di akun deposit Penelepon. Setelah setiap EndExecutionTransaction, Validator mengeluarkan pembayaran untuk pekerjaan yang dilakukan dan mengembalikan dana yang tidak digunakan ke Penelepon.

Validator melakukan pembayaran kepada Pelaksana terlepas dari apakah hasil eksekusinya berhasil atau tidak. Hadiah yang dikeluarkan adalah median dari semua Opini Pelaksana.

Klasifikasi Konten
Pemilik Drive dan Konsumen Konten dapat memilih Tag Deskripsi dari daftar tetap untuk mengklasifikasikan konten Sirius Storage (mis., batasan usia, genre) dan membuat konten dapat dicari.

Perangkat lunak aplikasi (misalnya, aplikasi jenis penelusuran Google atau aplikasi jenis YouTube) kemudian dapat menggunakan Tag Deskripsi untuk mengatur dan menampilkan konten yang sesuai.

Moderator & Larangan Jaringan
Konten Sirius Storage juga dapat dilarang dan dihapus dari jaringan untuk mencegah distribusi konten ilegal.

Pihak ketiga bernama Moderator (misalnya, organisasi swasta atau pemerintah) dapat memoderasi konten yang disimpan. Ada dua jenis Moderator:

1. Moderator Global: Menyensor konten di seluruh jaringan.
2. Moderator Lokal: Menyensor konten untuk yurisdiksi lokal.

Larangan Global
Moderator Global dapat mengidentifikasi konten berdasarkan Informasi Unduhan Konten (CDI) yang berisi hash unik file (seperti sidik jari) dan Tag Deskripsi. Setelah Moderator Global melarang file dengan memposting GlobalBanTransaction, jaringan akan menghapus file tersebut dari semua Drive, dan Konsumen Konten tidak dapat mengunduhnya lagi.

GlobalBanTransaction berfungsi sebagai modifikasi khusus untuk semua Drive yang berisi file karena memicu DataModificationApprovalTransactions gratis oleh Replikator Drive yang menyimpan file terlarang.

Jika Pemilik Drive mencoba mengunggah file yang dicekal secara global, Replikator akan mengabaikan permintaan tersebut dan tidak menyimpannya ke Drive.

Larangan Lokal
Larangan lokal dapat dijalankan melalui LocalBanTransaction oleh Moderator Global atau Moderator Lokal. Larangan lokal membuat peringatan bagi pengguna konten dan tidak memicu penghapusan otomatis konten dari Drive.

Setelah diberitahu tentang larangan lokal:

1. Pemilik Drive: Dapat menghapus file.
2. Replicator: Dapat dilepas dari Drive.
3. Konsumen Konten: Dapat membatalkan downland.

Pengembang dapat memprogram semua tindakan ini di perangkat lunak aplikasi.

Moderator Superkontrak
Superkontrak dapat digunakan untuk mengotomatisasi peran Moderator. Cara kerjanya:

1. Supercontract mendeteksi Tag Deskripsi atau keluhan yang disampaikan melalui Internet tentang konten yang dilarang.
2. Supercontract memeriksa apakah hash file cocok dengan konten yang dilarang.
3. Jika konten dilarang, Supercontract melepaskan transaksi larangan yang sesuai.

Tokenomics Tinjauan Konten
Review Unit (RW Unit) adalah Service Unit yang digunakan untuk layer Content Review. Validator mengirim ke Pemilik Drive dan Konsumen Konten 1 Unit RW untuk setiap Unit SM yang dibelanjakan. Pengguna platform hanya dapat menggunakan Unit RW untuk mengklasifikasikan konten.

Aliran proses:

1. Pemilik Drive atau Konsumen Konten memposting ReviewTransaction.
2. Transaksi telah melampirkan satu atau beberapa Tag Deskripsi yang dapat diterapkan jaringan ke satu atau beberapa file.
3. Transaksi juga menentukan berapa banyak Unit RW yang akan ditetapkan jaringan untuk setiap Tag Deskripsi. Semakin banyak Unit RW yang ditetapkan ke Tag Deskripsi, semakin banyak bobot yang dibawa tag untuk klasifikasi.

Dimana anda bisa membeli ProximaX coin ?

ProximaX memiliki Total Supply : 9,000,000,000 XPX

Jika Anda ingin tahu di mana membeli ProximaX dengan kurs saat ini, pertukaran mata uang kripto teratas untuk perdagangan saham ProximaX saat ini adalah MEXC, PancakeSwap (V2), dan ProBit Global.