Apa itu DSLA Protocol, DSLA Coin adalah

Apa itu DSLA Protocol, DSLA Coin ?

DSLA Protocol adalah kerangka kerja manajemen risiko yang memungkinkan operator dan pengembang infrastruktur mengurangi paparan pengguna mereka terhadap penundaan layanan, gangguan, dan kerugian finansial, menggunakan perjanjian tingkat layanan yang dijalankan sendiri, polis asuransi bonus-malus, dan kumpulan likuiditas urun dana.

Kasus penggunaan utama Protokol DSLA adalah untuk mengimbangi kerugian finansial dari delegator Proof-of-Stake dan pengguna DeFi, sambil memberi insentif pada konektivitas, kinerja, dan ketersediaan operator staking pool dan penyedia layanan DeFi.

DSLA Protocol, DSLA Coin

Meskipun tidak pernah semudah ini untuk mengekspos layanan online ke audiens global, memastikan bahwa mereka selalu memenuhi persyaratan kinerja, kapasitas, dan skalabilitas dari basis pengguna yang besar dan tidak dapat diprediksi tetap menjadi tantangan yang tidak perlu.
Bahkan tim teknik dan dukungan yang paling berbakat di seluruh dunia pada akhirnya harus menangani aliran kegagalan tanpa akhir yang disebabkan oleh kemacetan aplikasi dan komponen perangkat keras, perangkat lunak, dan konfigurasi yang mendasarinya.

Dalam makalah ini, kami membahas masalah dalam praktik manajemen tingkat layanan saat ini dan bagaimana Stacktical menghadirkan cara baru dan kreatif untuk menjamin keandalan pada skala layanan online, sekaligus memelihara kepercayaan dan menyelaraskan kepentingan antara pemangku kepentingan aplikasi.

Keandalan bisa dibilang fitur paling mendasar dari setiap layanan online.

Agar layanan online dapat dianggap andal, ia perlu memastikan pengalaman yang bebas bug, cepat, dan andal bagi penggunanya, perubahan demi perubahan, rilis demi rilis.

Tetapi dibandingkan dengan sejumlah besar alat yang membantu mengidentifikasi dan mengatasi bug dalam kandidat rilis perangkat lunak, perangkat lunak pengujian keandalan dan praktik seperti pengujian beban belum banyak berkembang selama beberapa dekade terakhir. Alat pengujian beban terdepan di industri ini masih LoadRunner, perangkat lunak yang dipelopori pada tahun 1999. Seperti alat lain di pasar, LoadRunner berjuang untuk menyesuaikan dengan metodologi pengembangan modern yang berfokus pada peningkatan kecepatan pengiriman ke lingkungan produksi.

Pengujian tidak hanya membutuhkan waktu beberapa hari untuk diselesaikan, tetapi juga menganalisis hasil pengujian menjadi wawasan skalabilitas yang dapat ditindaklanjuti terlalu bergantung pada intervensi manusia untuk diotomatisasi seperti jalur pengiriman lainnya.

Demi mengirimkan perangkat lunak secepat mungkin, penyedia layanan akhirnya memperkenalkan perubahan yang belum teruji pada lingkungan produksi mereka. Ini adalah pertukaran berisiko yang menciptakan kondisi sempurna untuk terjadinya kegagalan kinerja.

Deteksi dini regresi skalabilitas dengan mesin prediksi Stacktical

Tujuan pengujian keandalan adalah untuk memverifikasi bahwa kandidat rilis memenuhi Tujuan Tingkat Layanan (SLO) aplikasi. Mereka adalah Indikator Kinerja Utama yang memungkinkan Anda mengetahui apakah perubahan yang diusulkan dalam kode atau konfigurasi cocok untuk penerapan produksi.

Stacktical awalnya dikembangkan untuk merampingkan proses verifikasi menggunakan teknologi prediktif. Ini akan secara proaktif melindungi sistem produksi dengan menolak kandidat rilis yang tidak memenuhi persyaratan kinerja tertentu, tanpa memengaruhi kecepatan pengembangan.

Dengan menerapkan model matematika prediktif yang diwarisi dari Performance Theory untuk memuat tes, Stacktical mampu secara signifikan mengurangi durasinya, sekaligus memunculkan wawasan skalabilitas yang nyaris tidak dapat diinterpretasikan oleh manusia.

Pemodelan kinerja sistem mereka yang didorong oleh prediksi mendorong penyedia layanan untuk secara lebih proaktif mengatasi hambatan skalabilitas dan mencegah kegagalan kinerja, alih-alih hanya bereaksi terhadapnya dengan efisiensi di bawah standar.

Hingga saat ini, kekuatan pendorong utama di balik eksekusi kami sebagai perusahaan adalah ambisi kami untuk mengotomatiskan penyedia layanan dari pekerjaan mengelola regresi skalabilitas. Melalui prediksi belaka.

Skalabilitas aplikasi Cloud

Skalabilitas adalah keadaan yang sama untuk uang hosting Anda.

Kapasitas infrastruktur Cloud Anda—jumlah maksimum pengguna bersamaan dan transaksi per detik yang dapat ditanganinya—harus meningkat secara proporsional dengan sumber daya komputasi yang Anda tambahkan ke dalamnya.

Namun dalam praktiknya, penyedia layanan tidak akan dapat menangani dua kali transaksi per detik hanya dengan menggandakan jumlah instance Cloud (server) dalam infrastrukturnya.

Saat sistem mencapai kapasitas puncaknya, membuang sumber daya komputasi pada kode dan konfigurasi yang tidak dapat diskalakan hanya akan meningkatkan kinerja aplikasi sampai batas tertentu sebelum mulai mengalami kemunduran, sementara juga menimbulkan pemborosan modal yang semakin parah.

Bagan prediksi skalabilitas. Performa menurun tajam ketika sistem mencapai kapasitas puncaknya pada 338 pengguna bersamaan dan 1568 transaksi per detik.

Hal ini menjadikan kapasitas puncak sebagai metrik skalabilitas yang paling penting, dan menekankan fakta bahwa skalabilitas tidak dapat diabaikan dan harus lebih dekat dengan Siklus Hidup Pengembangan Perangkat Lunak.

Di belakang, skalabilitas adalah produk pertama dan terutama dari bagaimana aplikasi cloud direkayasa untuk menggunakan server cloudnya secara efisien dan terus mendorong metrik kapasitas puncak ke ketinggian baru seiring bertambahnya audiens.

Skalabilitas aplikasi Blockchain

Ketika kami menggambarkan masalah skalabilitas jaringan blockchain menggunakan pengukuran transaksi per detik, kami berdua berbicara tentang skala penggunaan yang berbeda dari platform blockchain yang diberikan, dan kapasitas puncak platform blockchain dalam hal transaksi per detik (TPS).

Karena platform saat ini memiliki TPS puncak yang bisa dibilang rendah, masih ada beberapa kasus penggunaan di luar industri keuangan, untuk aplikasi terdesentralisasi (dApps).

Kasus penggunaan transaksi berat seperti layanan jejaring sosial belum didesentralisasi di blockchain: platform yang ada tidak dapat memenuhi persyaratan kinerjanya saat ini.

Itu tidak berarti sekarang bukan waktunya untuk mengembangkan dApps sosial, karena kemajuan sedang dibuat pada kapasitas puncak jaringan blockchain setiap hari. Tetapi mungkin perlu satu dekade untuk menskalakan kasus penggunaan yang ada, dan memperkenalkan yang baru.

Sebagai layanan yang dibatasi oleh skalabilitas jaringan blockchain asli cloud dan terdesentralisasi, pertukaran cryptocurrency adalah perwujudan dari tantangan untuk memastikan skalabilitas layanan online.

Binance.com, misalnya, tidak hanya harus mampu mempertahankan beberapa ratus ribu pendaftaran per hari, tetapi mereka juga dipengaruhi oleh hambatan skalabilitas dari jaringan blockchain yang mereka dukung.

Menguji kinerja aplikasi berbasis Cloud

Untuk sebagian besar penyedia layanan, ada ketegangan yang jelas antara mengirimkan perangkat lunak secepat mungkin dan berinvestasi dalam menguji kinerja, kapasitas, dan skalabilitas setiap kandidat rilis perangkat lunak atau permintaan tarik.

Akibatnya, banyak penyedia akhirnya memilih strategi kuratif, yang dimungkinkan oleh pemantauan kinerja dan praktik manajemen insiden, daripada pengujian beban preventif dan perencanaan kapasitas, dalam hal merekayasa keandalan infrastruktur mereka.

Membuat pengujian beban lebih cerdas

Mempercepat pengujian beban dan meningkatkan cakupan pengujian dengan prediksi
Selama beberapa dekade, para peneliti telah membangun hubungan matematis antara metrik kinerja dan model yang dibuat yang membantu memprediksi evolusi mereka, seiring dengan meningkatnya pemanfaatan aplikasi.

Pada hari-hari awal Stacktical, kami memperkenalkan solusi turn-key untuk menerapkan model prediktif ini ke metrik kinerja yang dikumpulkan oleh penyedia saat mereka mengembangkan dan mengoperasikan aplikasi mereka. Hasilnya, tim DevSecOps lebih mudah mengemas pengujian beban maksimum dalam lingkungan Integrasi Berkelanjutan yang serba cepat, tanpa memengaruhi kecepatan pengembangan.

Mengotomatiskan interpretasi hasil pengujian beban ke dalam SLO

Dalam contoh Gambar. 2a berikut, proof-of-concept kami mencoba untuk memasukkan sampel kecil dari 8 hasil uji beban ke dalam model prediktif yang disebut Universal Scalability Law (USL).

Model ini memungkinkan kami untuk secara instan menghitung kapasitas puncak dari aplikasi yang diuji, memetakan skalabilitasnya, dan menghitung berapa banyak waktu eksekusi yang terbuang pada hambatan pertentangan dan koherensi dari komponen perangkat keras, perangkat lunak, dan konfigurasi yang mendasarinya.

Ini menggunakan regresi non-linier antara jumlah pengguna bersamaan yang terlibat dalam skenario uji beban dan jumlah transaksi per detik yang sesuai yang didukung oleh aplikasi.

Koefisien matematis yang dihasilkan dari regresi non-linier dari dua metrik sistem ini memungkinkan mesin Stacktical untuk memprediksi titik data yang tersisa di bagan skalabilitas, sekaligus menghitung penalti yang membuat bagan turun saat aplikasi mencapai kapasitas puncaknya.

Bersama dengan USL, kami menggunakan Little’s Law untuk memetakan waktu respons aplikasi saat beban meningkat dan memunculkan wawasan “Waktu Respons di Puncak”. Anda juga dapat melihat bahwa tidak ada pengoptimalan yang diperlukan untuk skenario pengujian ini, berdasarkan hambatan skalabilitas terukur.

Bahkan setelah berhari-hari melakukan analisis, seorang insinyur perangkat lunak tidak akan dapat memunculkan wawasan skalabilitas ini dari hasil pengujian input. Apalagi menggunakannya sebagai Service Level Objective (SLO).

Berbagi SLO dengan pemangku kepentingan internal

Karena hambatan skalabilitas merusak keberhasilan berbagai inisiatif strategis dalam organisasi, kami telah merancang laporan skalabilitas untuk dibagikan kepada siapa saja dan berbicara dalam bahasa yang dapat dipahami oleh semua pemangku kepentingan aplikasi.

Di atas dua pilar mendasar ini, tim kami merancang interaksi sosial yang semakin memberdayakan individu untuk bertindak secara kolektif di SLO, dan pada akhirnya meningkatkan profitabilitas layanan online dan terhubung organisasi.

Mengelola tingkat layanan

Karena kegagalan tidak pernah dapat sepenuhnya dihilangkan, mendefinisikan SLO untuk memastikan keandalan aplikasi hanyalah bagian dari persamaan keberhasilan pelanggan.

Setelah bekerja selama 2 tahun untuk merampingkan definisi dan pengukuran SLO, kami menyadari sesuatu yang sederhana: tidak peduli seberapa baik praktik Site Reliability Engineering (SRE) mereka, tidak ada tim yang dapat mencegah layanan pihak ketiga pada akhirnya turun.

Seiring dengan praktik pengujian beban yang hebat, juga sangat penting untuk menawarkan jaminan pada kinerja yang dapat diharapkan pelanggan dari layanan yang mereka bayar, dan menetapkan protokol tentang cara yang adil untuk menyelesaikan perselisihan dalam situasi non-kinerja.

Service Level Agreements (SLA) menyediakan kerangka kerja yang mengikat secara hukum yang bertujuan untuk mendefinisikan dan menegakkan kualitas persyaratan Layanan tersebut.

Tetapi apakah SLA memenuhi misi awal mereka dan apakah mereka mampu memenuhi harapan semua pemangku kepentingan aplikasi sehubungan dengan acara kinerja?

Praktik manajemen tingkat layanan tradisional rusak

Di dunia di mana masyarakat umum jarang membaca persyaratan yang mereka setujui, penyedia tidak terlalu tertarik untuk mendefinisikan perjanjian tingkat layanan yang adil.

Namun, ketika pengguna benar-benar peduli untuk menanggung risiko yang terkait dengan tingkat layanan yang buruk-karena kemungkinan besar mereka merusak profitabilitas organisasi mereka sendiri-mereka menginvestasikan sejumlah besar waktu, pengeluaran operasional, dan biaya hukum untuk menjembatani kesenjangan antara harapan mereka dan SLA. kebijakan, yang secara matematis menentang tujuan mencari kompensasi atas kegagalan kinerja di masa depan.

Ini bukan hanya sifat sepihak dari kebijakan SLA atau kesulitan yang tidak perlu dalam merundingkan kebijakan. Secara keseluruhan, inefisiensi SLA pada setiap langkah dari siklus hidupnya mengisyaratkan kelemahan utama yang belum ditangani.

Mendefinisikan Perjanjian Tingkat Layanan

Untuk dapat menyepakati tingkat layanan, pemangku kepentingan perlu menyepakati metrik kinerja, kapasitas, dan skalabilitas yang akan menjadi dasar untuk menegakkan SLA dan menangani pelanggaran.

Kompleksitas dalam mendefinisikan, mengukur SLO melalui praktik pengujian kinerja membuatnya sama rumitnya untuk mendefinisikan perjanjian yang bermakna.

Menegosiasikan Perjanjian Tingkat Layanan

Karena tidak ada pemangku kepentingan selain penyedia itu sendiri yang bertanggung jawab atas definisi kebijakan tingkat layanan, sulit bagi Perjanjian Tingkat Layanan untuk tidak memihak penyedia itu sendiri alih-alih menyelaraskan kepentingan semua pemangku kepentingan aplikasi.

Selama negosiasi, kesepakatan hanya dapat ditentang oleh pengguna sampai batas tertentu. Semakin banyak pengguna ingin

kebijakan untuk memenuhi harapan mereka, semakin banyak keterampilan dan sumber daya yang harus dituangkan ke dalam perencanaan, diskusi, dan biaya hukum.

Memantau Perjanjian Tingkat Layanan

Sebagian besar implementasi Perjanjian Tingkat Layanan tidak cukup halus untuk mempertimbangkan semua tingkat keparahan kegagalan. Sementara platform Pemantauan Kinerja Aplikasi menyediakan penyedia layanan dengan pengawasan real-time dari layanan online mereka, data ini tidak digunakan untuk memantau pelanggaran.

Beberapa penyedia bahkan mengharuskan pengguna untuk membawa bukti nyata bahwa pemadaman telah berdampak negatif pada operasi mereka untuk memulai penegakan perjanjian.

Menegakkan Perjanjian Tingkat Layanan

Jika terjadi penghentian produksi dan mempertimbangkan waktu henti yang diakibatkannya, pengguna yang berhak atas pemulihan dipaksa untuk secara proaktif meminta kompensasi yang hanya akan efektif beberapa minggu, jika tidak berbulan-bulan setelah peristiwa tersebut.

Karena berbagai pemadaman dan dampak bisnisnya hampir tidak dapat diantisipasi dan diperkirakan, penyedia hanya dapat melakukan pengembalian sebagian belanja modal. Untuk lebih mengurangi kerugian yang ditimbulkan dengan situasi non-kinerja, pengguna harus bergantung pada perusahaan asuransi, yang semakin menambah kompleksitas proses yang sudah kompleks.

Menciptakan kembali Manajemen Tingkat Layanan dengan Protokol DSLA

Dengan menggunakan blockchain untuk menghapus perantara yang terlibat dalam Manajemen Tingkat Layanan, Protokol DSLA bertujuan menyederhanakan definisi, negosiasi, pemantauan, dan penegakan Perjanjian Tingkat Layanan secara radikal, sambil terus menyelaraskan kepentingan semua pemangku kepentingan aplikasi.

Dikombinasikan dengan pengalaman pengguna yang menjembatani kesenjangan antara teknik pemodelan kinerja, harapan pengguna terhadap kinerja penyedia dan praktik manajemen rilis, Protokol DSLA menjadi kerangka kerja Manajemen Tingkat Layanan Terdesentralisasi dengan efisiensi tinggi yang dapat memenuhi misi awal SLA dengan lebih sedikit pertukaran. off, jika ada.

Merampingkan perundingan bilateral kebijakan Perjanjian Tingkat Layanan

Tahap definisi dan negosiasi dari siklus hidup Perjanjian Tingkat Layanan sangat membutuhkan pengalaman pengguna yang lebih baik dan data kinerja yang lebih nyata.

Membingkai masalah kinerja, kapasitas, dan skalabilitas dengan jawaban hukum telah menunda, jika tidak mencegah perangkat lunak yang menarik dan solusi manajemen tingkat layanan muncul di pasar.

Sebagai sebuah perusahaan, dan mengikuti tradisi pemberdayaan pemangku kepentingan, kami bermaksud untuk mendistribusikan platform pemodelan Perjanjian Tingkat Layanan pertama yang benar-benar partisipatif.

Karena semua pemangku kepentingan akan memiliki akses ke wawasan skalabilitas yang dihasilkan oleh pembungkus uji beban prediktif kami, kebijakan tawar-menawar akan didorong oleh data alih-alih dimotivasi oleh kebutuhan penyedia untuk melindungi dirinya sendiri, atau satu-satunya harapan klien tentang kinerja layanan.

Perjanjian Tingkat Layanan sebagai Kontrak Cerdas

Kontrak Cerdas di blockchain adalah kontrak digital yang dapat diprogram dan dijalankan sendiri yang memfasilitasi, memverifikasi, dan melaksanakan ketentuan perjanjian yang diberikan antara pengguna di blockchain.

Mereka bertanggung jawab untuk mengakses dan menyimpan data publik yang terdesentralisasi dengan sifat yang berbeda. Karena tidak ada yang memiliki atau dapat merusak data tersebut, semua orang dapat mempercayainya.

Diterapkan pada Manajemen Tingkat Layanan, Kontrak Cerdas akan memungkinkan penyedia untuk mendelegasikan tanggung jawab pembuatan Perjanjian Tingkat Layanan kepada komunitas.

Mereka akan mengotomatiskan penyelesaian pelanggaran tingkat layanan.

Perjanjian Tingkat Layanan Business-to-Many

SLA selalu disediakan untuk jenis pemangku kepentingan tertentu, pada dasarnya bisnis.

Memanfaatkan manfaat dari platform Blockchain publik dan kemampuannya untuk mengotomatisasi penegakan Perjanjian Tingkat Layanan Terdesentralisasi, Protokol DSLA menjauh dari konteks bisnis-ke-bisnis tradisional dari perjanjian tersebut dan memungkinkan untuk memberi insentif kepada semua jenis pemangku kepentingan layanan, berdasarkan tingkat layanan yang dipantau.

Ini adalah variasi kerangka kerja peer-to-peer yang pernah dibuat, dan cerminan sejati dari keyakinan kami bahwa siapa pun harus didorong dalam menghadapi kegagalan dan keberhasilan kinerja.

Pemantauan Perjanjian Tingkat Layanan berbasis Oracle

Untuk memicu penerapan SLA, platform Protokol DSLA harus dapat mendeteksi kegagalan kinerja dan mengomunikasikan informasi tersebut ke Kontrak Cerdas yang bertanggung jawab untuk memberi kompensasi kepada pengguna. Karena metrik Pemantauan Kinerja Aplikasi bukan bagian dari jaringan blockchain, metrik tersebut perlu bersumber dari tempat lain, dari dunia offchain.

Oracle adalah layanan gateway yang menghubungkan blockchain dengan data lain yang tersedia di Internet dan dunia fisik.

Kami berencana menggunakan jaringan Oracle yang terdesentralisasi untuk mengumpulkan metrik kinerja yang mendekati waktu nyata dari berbagai sumber analitik.

Selama lokakarya internal kami, sistem ping terdesentralisasi dan terdistribusi telah muncul sebagai implementasi pertama yang layak dari pemantauan uptime berbasis Oracle di platform Protokol DSLA.

Sejalan dengan implementasi Oracles kami sendiri, kami akan memantau secara ketat Sistem Manajemen Oracle yang muncul untuk melihat apakah mereka menyediakan tingkat desentralisasi dan kepercayaan yang kompatibel dengan kebutuhan pemantauan khusus kami.

Kami juga akan mengeksplorasi kemungkinan sumber metrik dari platform Pemantauan Kinerja Aplikasi pelanggan kami.

Bersama dengan Oracle yang berfokus pada deteksi, Protokol DSLA akan menggunakan kombinasi kinerja aplikasi, layanan pelanggan, dan perilaku pengguna Oracle untuk menghitung formula kompensasi token DSLA yang digunakan oleh Kontrak Cerdas kami.

Arsitektur berbasis Oracle kami tidak harus berbasis server karena mencapai bentuk konsensus sisi klien adalah cara yang mungkin untuk merancang solusi yang layak yang melibatkan pemangku kepentingan yang tidak memihak.

Memperkenalkan token DSLA

Token DSLA adalah mesin Protokol DSLA yang mudah terbakar:

• Penyedia Likuiditas menghabiskan token DSLA untuk menerbitkan perjanjian tingkat layanan ke pasar.
• Token DSLA kemudian memberi penghargaan kepada peserta protokol DSLA untuk menyelesaikan tugas pemeliharaan protokol.
• Token DSLA akan dibakar selamanya, setiap kali tugas pemeliharaan selesai.

Memberi kompensasi kepada pemangku kepentingan aplikasi internal dan eksternal

Menggunakan token DSLA dan Perjanjian Tingkat Layanan Terdesentralisasi dari platform Protokol DSLA, perusahaan dapat secara otomatis mengganti kerugian pelanggan mereka atas kegagalan kinerja, sambil memberi penghargaan kepada tim dukungan mereka untuk keunggulan operasional.

Middleware manajemen risiko Protokol DSLA, dan token DSLA, dirancang untuk menyelaraskan kepentingan semua pemangku kepentingan aplikasi, dalam situasi kinerja dan non-kinerja.

Penyedia memulai dengan menentukan tujuan tingkat layanan dan mempertaruhkan token DSLA untuk membentuk kumpulan likuiditas. Kumpulan likuiditas habis sesuai dengan tingkat layanan yang baik dan tingkat layanan yang buruk.
Pemangku kepentingan dapat menarik DSLA yang mereka klaim sebagai kompensasi ke dompet yang kompatibel dengan ERC-20 dan menggunakannya kembali dalam Protokol DSLA.

Ekonomi ini secara efektif mendaur ulang pemborosan waktu atau uang menjadi waktu dan modal layanan tambahan.

Distribusi Protokol DSLA

Tim pengembangan inti Protokol DSLA telah merancang pasokan token DSLA untuk mencapai salah satu distribusi paling adil di industri.

Protokol DSLA adalah proyek bootstrap yang menunjukkan ketahanannya, tanpa tekanan dari modal ventura dan sumber pendanaan eksternal.

Sebagian besar token DSLA ada di tangan komunitas kami, dengan lebih dari 90% token DSLA beredar di pasar.

Penggunaan Cadangan

Cadangan perusahaan token DSLA (0xf428) digunakan untuk mengarahkan pelanggan baru ke Protokol DSLA dan menangani pengeluaran operasional seperti biaya daftar bursa.

Cadangan komunitas token DSLA (0xf428) digunakan untuk memasukkan pengembang baru ke ekosistem Protokol DSLA, dan mempertahankan operasi program Residensi DSLA.

Jadwal Vesting
Sejak Protokol DSLA telah beroperasi sejak 2018, semua penguncian token telah kedaluwarsa sekarang.

Kontributor/ Tim Protokol DSLA

Pendiri
Protokol DSLA telah didirikan oleh eksekutif ITSM dengan pengalaman gabungan 30+ tahun di Site Reliability Engineering (SRE). Tim pengembangan inti terdiri dari 10 individu, yang secara aktif memelihara basis kode protokol dan mendukung operasinya.

Wilhem Pujar
Co-founder, CEO, VP Produk
Manajer Produk Senior & Arsitek Perangkat Lunak

Wilhem memegang gelar MSc dalam Ilmu Komputer. Dia memiliki pengalaman 12 tahun dalam arsitektur perangkat lunak terdistribusi, pengembangan perangkat lunak dan manajemen produk.

Dia sebelumnya mendirikan Tag&See, sebuah startup Big Data yang berspesialisasi dalam pemantauan media sosial dan analisis sentimen.

Dia mulai terlibat dengan cryptocurrency pada tahun 2015, dengan bereksperimen dengan pengembangan kode rantai di IBM Bluemix, salah satu komponen asli dari apa yang sekarang dikenal sebagai konsorsium Hyperledger.

Jean Daniel Bussy
Co-founder, CTO, VP Cloud
Arsitek Cloud & Blockchain Senior

Jean-Daniel memegang gelar MSc di bidang Ilmu Komputer. Dia adalah Arsitek Bersertifikat Google dan Kubernetes dengan pengalaman 12 tahun di bidang Administrasi Sistem, IaaS, Manajemen Kinerja, dan Arsitektur Cloud

Dia telah menjadi salah satu administrator OpenStack dan Kubernetes pertama di Asia.

Dia mulai terlibat dengan cryptocurrency pada tahun 2014, ketika dia menerapkan prinsip otomatisasi DevOps untuk penyebaran node Litecoin.

Mitra Protokol DSLA

Pendukung termasuk, tetapi tidak terbatas pada:

• FinTech Prancis
  Asosiasi FinTech terkemuka Prancis
• ADAN
  Asosiasi blockchain terkemuka di Prancis
• BPIF Prancis
  Bank publik Prancis untuk inovasi
• Rantai
  Penyedia Layanan Oracle
• Protokol pita
  Penyedia Layanan Oracle
• XYO
  Penyedia Layanan Geo Oracle
• Certik
  Perusahaan Audit & Keamanan Kontrak Cerdas
• Lab Nomadik
  Pengembang Inti Tezos
• Harmoni
  Pengembang Inti Harmoni
• Ava Labs
  Pengembang Inti Longsor
• Lab Oasis
  Pengembang Inti Oasis
• Fauna
  Komunitas DevSecOps terkemuka di dunia

Daftar lengkap mitra Protokol DSLA dan anggota ekosistem tersedia di https://stacktical.com

Dalam makalah ini, kita telah melihat keterbatasan saat ini dan efisiensi yang buruk dalam membingkai masalah kinerja, kapasitas dan skalabilitas menggunakan jawaban hukum.

Kami telah menemukan bagaimana Protokol DSLA bekerja untuk mengurangi kegagalan kinerja dan mengelola situasi non-kinerja menggunakan ilmu data dan teknologi blockchain.

Sebagai solusi infrastruktur untuk masalah infrastruktur, Protokol DSLA akhirnya dapat memenuhi misi asli dari kerangka kerja perjanjian tingkat layanan: menetapkan dan menegakkan kebijakan adil berbasis data yang mengurangi risiko bagi pelanggan sekaligus memberikan nilai bisnis bagi penyedia layanan pihak ketiga.

Dimana anda bisa membeli DSLA Protocol coin ?

DSLA Protocol memiliki maksimal pasokan 5.831.304.407 koin DSLA.

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

Referensi : Protokol DSLA Whitepaper