Dalam posting terakhir kami, kami menjelaskan bagaimana Radix Engine, sebagai bagian dari tumpukan teknologi Radix, memberikan terobosan pembangunan dengan mengambil pendekatan "berorientasi aset" untuk pengembangan DLT, daripada kontrak pintar khas saat ini. Pendekatan ini tidak hanya lebih mudah - tetapi juga meningkatkan kualitas hasil. Contoh yang sangat baik dari ini adalah bagaimana Radix memungkinkan "komposabilitas" aplikasi DLT yang jauh lebih baik.
Komposabilitas adalah salah satu konsep paling kuat dalam arsitektur perangkat lunak, dan baru-baru ini menjadi topik perdebatan di dunia DLT. Beberapa mulai khawatir bahwa Ethereum mungkin tidak dapat disusun seperti yang diinginkan banyak pengembang, dan bahwa memecah Ethereum untuk meningkatkan throughputnya dapat membuat masalah menjadi lebih buruk. Kompatibilitas kontrak pintar yang buruk mungkin sebenarnya menjadi faktor penting dalam kegagalan DLT untuk mencapai adopsi yang luas dalam aplikasi saat ini. Apa sebenarnya komposabilitas dan mengapa itu penting?
Komposabilitas Menciptakan Web Modern
Mari kita mulai dengan kisah sukses komposabilitas yang bisa dibilang menopang sebagian besar penggunaan Internet saat ini.
Internet dan Web (protokol HTTP) memberi kita lapisan komunikasi tempat pengguna dan perusahaan dapat berkomunikasi dengan bebas. Tetapi selama bertahun-tahun, “aplikasi” di Web sebagian besar merupakan pulau data: pengguna dapat meminta halaman web dan berinteraksi dengannya hanya dengan cara yang sangat khusus (melalui permintaan lebih lanjut). Komunikasi antar aplikasi jarang terjadi karena integrasi memerlukan pembuatan antarmuka khusus. HTTP sendiri seperti bazaar terbuka tempat para pedagang dapat berbicara, tetapi di mana ribuan bahasa digunakan, membuat komunikasi di antara mereka menjadi sulit atau praktis tidak mungkin.
Agar Web mencapai potensi penuhnya, penghalang ini harus dihancurkan; pengembang membutuhkan lebih dari sekadar HTTP. Mereka membutuhkan lingua franca sederhana (bahasa penghubung singkat untuk tujuan tertentu) yang berbicara secara sederhana tentang apa yang terbaik untuk HTTP: mengirim dan menerima pesan. Cara baru menggunakan HTTP yang disebut REST akhirnya menyediakan bahasa yang tepat untuk tugas tersebut, membuat aplikasi yang sangat berbeda terlihat seperti penerima dan pengirim pesan menggunakan jenis antarmuka yang sama. Tiba-tiba interoperabilitas antar aplikasi menjadi asli, mudah, intuitif. Hasilnya, inovasi di Web berkembang pesat.
Bagaimana REST mencapai ini? Ini membentuk satu set sederhana dari komponen berorientasi pesan. Komponen ini mendorong pengembang untuk memikirkan fungsionalitas aplikasi mereka dalam hal pesan sederhana yang dapat dikirim dan diterima. Setiap aplikasi yang menawarkan "RESTful API" disarikan sebagai "layanan" (sehingga penawaran cloud "perangkat lunak sebagai layanan" umum saat ini). Setiap pengembang dapat dengan cepat menggunakan - dan menggabungkan - layanan RESTful, tidak peduli seberapa kompleks layanan di dalamnya. 
Pengembangan fungsionalitas berorientasi pesan yang dapat digabungkan menggunakan titik akhir API RESTful
Hal ini membuat layanan RESTful sangat mudah disusun; pengembang dapat membuat aplikasi baru yang dengan mudah menyusun layanan RESTful yang ada bersama-sama untuk membuat sistem dan fungsionalitas baru yang tidak pernah diantisipasi oleh penyedia layanan. (Ini telah menjadi model bisnis utama dari banyak perusahaan "integrator solusi" yang sangat sukses saat ini.)
Pendekatan ini berguna tidak hanya di Web terbuka, tetapi juga di dalam perusahaan. Konsep "layanan mikro" telah menangkap banyak pengembangan sistem backend dengan mengambil pendekatan yang sangat mirip dengan REST. Fungsionalitas backend dikemas di balik API perpesanan abstrak sederhana, yang memungkinkan integrasi cepat dan penambahan fungsionalitas baru dan tak terencana yang dapat diprediksi di masa mendatang.
Masalah dengan Kontrak Cerdas yang Dapat Disusun
Asumsi umum di dunia blockchain dan DLT saat ini adalah bahwa aplikasi DLT harus dibuat menggunakan kontrak pintar, masing-masing mewakili fungsi kotak hitam. Di sini "komposabilitas" mengambil bentuk komunikasi antara kontrak pintar yang menerima dan bertindak berdasarkan pesan on-chain (atau on-ledger). Ini sangat mirip dengan model komposabilitas REST untuk Web - cukup dipindahkan ke blockchain atau DLT lainnya. 
Kontrak pintar DLT yang khas mendorong pola interoperabilitas berorientasi pesan yang mirip dengan Web
Ini tampak intuitif di permukaan, tetapi memaksa model komposabilitas berorientasi pesan ke teknologi yang berbeda secara fundamental dan serangkaian kebutuhan menghadirkan kesulitan bagi pengembang. Ingatlah bahwa bahasa yang tepat harus dirancang untuk jenis masalah khusus yang coba dipecahkan oleh pengembang dengan teknologi tersebut. Saat membuat layanan data berbasis web, model berorientasi pesan sesuai dengan harapan pengembang - tetapi ketika membuat transaksi berbasis DLT, model tersebut rusak seperti yang akan kita lihat.
Ambil, sebagai contoh yang disederhanakan, "masalah kereta dan hotel" yang sering dikutip dalam diskusi komposabilitas di komunitas Ethereum saat ini. Dalam contoh ini, seorang pelancong ingin membeli tiket kereta api dan kamar hotel di tujuan - tetapi tidak ingin membeli tiket maupun kamar jika salah satunya tidak tersedia. Dalam model kontrak pintar, tiket kereta api, reservasi hotel, dan uang disediakan oleh kontrak pintar independen, masing-masing dengan antarmuka pengiriman pesan. 
Koneksi perpesanan yang harus dikelola pengembang untuk melakukan satu transaksi "kereta api dan hotel"
Pengembang lebih suka menganggap ini sebagai transaksi tunggal. Namun menggunakan model berorientasi pesan, transaksi harus dibangun dalam hal proses escrow multi-langkah. Pesan "Debit" dan "kredit" membuat pesan "tanda terima" yang dapat diedarkan, memastikan bahwa uang tersebut tidak dimasukkan ke dalam kontrak cerdas kereta dan hotel yang terpisah sampai kereta dan hotel merespons bahwa mereka bersedia melakukan penjualan. Ini adalah metode komposabilitas yang direkomendasikan untuk Ethereum. 
Contoh pesan kontrak pintar yang dapat disusun, dari wiki Ethereum Masalah kereta-dan-hotel sangat sederhana, tetapi sudah berat bagi pengembang yang hanya ingin satu transaksi. Bayangkan mencoba membuat transaksi kompleks antara, katakanlah, beberapa penyedia layanan keuangan - masing-masing harus membangun dukungan debit / kredit / penerimaan yang aman ke dalam kontrak pintar mereka - di mana uang sungguhan dipertaruhkan. Semakin banyak layanan kontrak pintar yang ingin dibuat bersama oleh pengembang, semakin banyak pesan yang harus diatur, dan semakin banyak beban bagi pengembang. Ini jelas bukan fungsionalitas yang bisa disusun.
Baru-baru ini, ada perdebatan tambahan di komunitas Ethereum seputar komposabilitas. Pengembang lebih suka jika pesan permintaan / tanda terima yang diperlukan semuanya diteruskan dengan cepat dan sinkron, berfungsi secara efektif sebagai satu sistem. Namun, sharding status yang diusulkan Eth2 akan memaksa kontrak pintar untuk hidup di pecahan yang berbeda dan oleh karena itu pesan yang diteruskan di antara mereka akan menjadi asinkron. Sementara model komposabilitas berorientasi pesan akan tetap berfungsi, sharding akan menambah beban developer lebih lanjut dan meningkatkan latensi transaksional.
Secara keseluruhan, metode kontrak pintar yang diasumsikan mencoba untuk memaksa DLT secara tidak wajar ke dalam cetakan teknologi yang berbeda. Membuka kunci potensi penuh DLT memerlukan pola baru yang mendorong pengembang untuk memikirkan aplikasi berbasis DLT mereka dalam hal komponen yang sesuai dengan teknologi.
Komposabilitas Berorientasi Aset untuk DLT
Seperti yang ditunjukkan contoh REST kepada kita, untuk membuat DLT benar-benar dapat disusun, kita memerlukan bahasa asli yang menggunakan komponen sederhana untuk mendorong pengembang "berbicara" secara langsung tentang apa yang paling cocok untuk DLT. Web adalah teknologi komunikasi yang membutuhkan bahasa pesan. DLT adalah teknologi transaksi yang membutuhkan bahasa aset baru untuk membuat interoperabilitas antara aplikasi DLT menjadi asli, mudah, dan intuitif.
Baik kita berbicara tentang cryptocurrency atau penerbitan obligasi, CryptoKitties atau rantai pasokan waktu nyata, DeFi atau IoT, identitas berdaulat atau pemilihan nasional - semua aplikasi ini secara intuitif dipecah menjadi transaksi aset seperti koin, obligasi, barang koleksi, produk , pinjaman, paket data, identitas, atau suara. Tugas DLT adalah melakukan transaksi sesuai dengan aturan unik masing-masing aset yang menjadi model harapan pengembang tentang bagaimana mereka harus berperilaku.
Untuk menggunakan contoh kereta dan hotel, aplikasi DLT yang benar-benar dapat disusun akan memungkinkan pengembang membuat satu transaksi di seluruh bisnis yang hanya mengatakan: "beli tiket kereta dan kamar hotel ini, menggunakan uang saya". Bahasanya bukan pesan, melainkan tiket, kamar, dan uang. Bisnis dan aplikasinya kemudian menjadi penerbit, menentukan aturan yang harus diikuti aset mereka, seperti "tiket kereta api adalah aset yang tidak dapat dialihkan yang tersedia saat dapat dibeli dan memiliki harga terkait dalam mata uang tertentu".
Dengan aset yang diberlakukan secara mandiri yang diterbitkan di DLT, penyusunan fungsi baru di seluruh bisnis, seperti pembelian kereta dan hotel kami, menjadi sederhana dan langsung. Pengembang dapat meminta satu transaksi "atomik" yang intuitif yang mencakup tiket dan kamar, menggunakan mata uang yang sesuai untuk masing-masing, meskipun aset ditentukan dan dikendalikan oleh penerbit yang berbeda. DLT kemudian dapat dengan benar menerima atau menolak seluruh transaksi yang diminta sekaligus, sesuai keinginan pengembang, tanpa upaya pengembang khusus. 
Melakukan transaksi "kereta-dan-hotel" di seluruh bisnis dalam satu langkah intuitif
Kita dapat membayangkan fungsionalitas komposisi yang jauh lebih kompleks. Mungkin sebuah aplikasi ingin menggunakan lusinan aset yang tersebar di banyak penerbit, mencampur dan membangun di atas representasi yang dapat dioperasikan dari basis pengguna dan produk mereka. Mungkin aset ini kadang-kadang dapat dikendalikan oleh fungsionalitas "off-ledger" yang kompleks dalam sistem back-end bisnis. Antarmuka yang dapat disusun masih merupakan aset, dan setiap transaksi yang diminta oleh pengembang juga sesederhana itu.
Seperti halnya REST, pendekatan ini berguna tidak hanya untuk sistem transaksional pada platform DLT publik atau konsorsium, tetapi juga untuk penerapan pribadi. Ini karena komposabilitas aset memungkinkan integrasi tidak hanya beberapa bisnis - tetapi memungkinkan beberapa sistem dalam bisnis yang kompleks untuk berbagi satu "sumber kebenaran", dan membangun fungsionalitas baru di atasnya. Misalnya, bisnis dapat dengan cepat membangun sistem akuntansi lintas departemen internal, dan kemudian dapat mengembangkannya menjadi platform pembayaran pelanggan tanpa melakukan refactoring seluruh back-end mereka. Komposisi sejati membuat DLT menjadi teknologi integrasi generasi mendatang yang andal.
Pergerakan ke DLT yang Dapat Dikomposisi Secara Asli
Seperti halnya Web, mencapai potensi penuh DLT memerlukan pemikiran ulang paradigma pengembangan aplikasi DLT dari perspektif pengembang di mana komposabilitas adalah kuncinya. Beberapa platform DLT mulai mengenali kebutuhan ini dan mengambil pendekatan berorientasi aset. Stellar berfokus pada penerbitan dan pengelolaan aset yang didukung fiat oleh penyedia layanan keuangan. NEM menyediakan token sederhana dan fitur akun multi-sig yang dapat memodelkan banyak jenis aset. Pembaruan terbaru Algorand menawarkan lapisan "Aset Standar" yang asli dan fleksibel. Bahkan bahasa kontrak pintar Libra's Move didasarkan pada pembuatan "sumber daya" yang menjadi model perilaku aset dasar.
Seperti yang kami jelaskan di posting terakhir kami, Radix dan Radix Engine-nya dirancang dari awal dengan pendekatan berorientasi aset yang kuat dan asli. Ini menyediakan komponen bawaan yang memungkinkan pengembang untuk mengekspresikan kebutuhan aplikasi mereka dalam hal aset yang relevan dengan bisnis yang ditangani sebagai warga kelas satu oleh Radix. Kami yakin hal ini menjadikan Radix platform paling alami untuk aplikasi DLT yang praktis, aman, dan dapat disusun secara native untuk kasus penggunaan dunia nyata. Dan desain Radix Engine dan Ledger yang praktis memungkinkan solusi yang dihasilkan untuk menyesuaikan dengan throughput yang kami perkirakan akan diminta oleh penggunaan DLT yang sangat mudah disusun.
Translator:
Radvocate Kukilo Ski
