Lapisan Tellor

Latar belakang

Penggunaan protokol Tellor saat ini semakin meluas, dengan sistem yang telah menunjukkan keamanannya di berbagai jaringan EVM. Namun, perubahan kripto yang terus-menerus telah membuat tim Tellor mengenali tren yang menandakan potensi tantangan bagi struktur protokol Tellor yang ada di tahun-tahun mendatang, khususnya:

1. Munculnya Rantai Khusus Aplikasi:

• Ribuan rantai, masing-masing disesuaikan untuk aplikasi spesifik, diperkirakan akan muncul.

2. Tidak Ada Sistem Asli yang Dominan:

• Tidak ada satu pun sistem asli yang akan menang. Banyak proyek akan beroperasi sebagai L1 individual, sementara proyek lain mungkin menggunakan lapisan DA seperti Ethereum, Celestia, atau menggunakan zona keamanan bersama sebagai hub.
• Hub akan ditandai dengan biaya tinggi dan transaksi lambat. Memanfaatkan titik-titik pusat ini akan menjadi sangat tidak efisien, dengan kemungkinan biaya transfer token di mainnet Ethereum melebihi $1.000 pada dekade berikutnya.

3. Kemajuan dalam Trustless Bridging:

• Dengan munculnya jembatan klien ringan (zk atau tidak), model hub-and-spoke tradisional (yang menjadi tujuan banyak rantai monolitik) kemungkinan besar akan terganggu.
• Perbedaan antara L2 yang berdaulat dan L1 dengan jembatan yang tidak dapat dipercaya akan sangat minim. 

4. Peningkatan Kecepatan, Finalitas, dan Kebutuhan Keamanan:

• Ketika kasus penggunaan kripto mulai menyaingi alternatif Web2, akan ada permintaan terus-menerus untuk peningkatan kecepatan, finalitas, dan keamanan dalam transaksi.

Mempersiapkan Tellor Menyongsong Masa Depan

Jadi, bagaimana kita membentuk Tellor sebagai protokol dan perusahaan di masa depan? Bagaimana kita bisa menciptakan oracle terbaik? Bagaimana kita menjadikan protokol Tellor sebagai oracle pilihan untuk proyek yang ingin mengintegrasikan data yang cepat dan aman di rantai apa pun tanpa mengorbankan prinsip-prinsip inti?  

Yang Tidak Dapat Dinegosiasikan:

• Desentralisasi : Protokol Tellor harus tetap terdesentralisasi dengan risiko DAO atau tata kelola yang minimal.

• Interoperabilitas : Protokol Tellor harus bekerja pada rantai apa pun tanpa perlu menjembatani token di sana.

• Menangani Kueri Non-Deterministik : Mengandalkan API saja tidak cukup. Fokusnya harus pada kumpulan yang dikelola dan kualitas data yang tinggi. Tellor harus berfungsi sebagai pembuat data, bukan sekadar penyedia data, dan fokus pada konsensus lunak/sosial.

Tujuan Tambahan:

• Kemampuan untuk Mengelola Volume Data Besar : Misalnya, menangani data survei, atau kumpulan input besar dengan cepat dan terjangkau untuk penggunaan on dan off-chain.

• Keamanan yang Ditingkatkan : Sistem harus aman tanpa batas, dengan protokol individual dapat menambahkan keamanan pada akhirnya.

• Kerangka Kerja untuk Rantai Non-EVM : Sistem harus dirancang untuk mengakomodasi rantai EVM dan non-EVM.

• Ekspansi Aditif : Penambahan rantai atau protokol baru harus bersifat saling melengkapi dan bukan kompetitif.

• Membatasi MEV : Praktik MEV yang tersebar luas saat ini dan pelaporan yang dilakukan oleh reporter protokol Tellor harus diatasi, karena akan bermanfaat bagi sistem untuk mengurangi praktik ini.

Dengan mengatasi kekhawatiran ini dan mencapai tujuan-tujuan ini, Tellor dapat ditempatkan secara strategis untuk berkembang dalam lanskap kripto yang berkembang pesat. Arah ini akan memastikan bahwa protokol Tellor terus berfungsi sebagai oracle terkemuka sambil beradaptasi dengan kebutuhan dan tuntutan ekosistem kripto yang terus berubah.

Lapisan Tellor

Tellor Layer adalah evolusi berikutnya untuk protokol Tellor. Ini adalah sistem untuk mencapai konsensus mengenai data apa pun dan akan dibuat sebagai rantai mandiri yang dibangun dengan mekanisme konsensus Cosmos SDK dan CometBFT.  

Ringkasan

Tellor Layer bekerja dengan validator yang mengirimkan jawaban atas pertanyaan. Setelah satu validator mengirimkan jawaban, semua validator harus mengirimkan jawaban mereka sendiri ke kueri atau cukup memvalidasi bahwa seseorang mengirimkan nilainya. 

 

Konsensus

Validator tidak dipaksa untuk menggunakan klien standar dan dapat memilih untuk mendukung salah satu atau semua kueri oracle bergantung pada tujuan masing-masing. Fleksibilitas ini memungkinkan tingkat keamanan yang berbeda untuk berbagai jenis data.

Untuk pertanyaan dengan dukungan tingkat konsensus yang luas, hampir semua validator rantai akan langsung menyetujui informasi tersebut. Contohnya adalah panggilan API, median dari beberapa panggilan API, atau beberapa bentuk informasi lain yang tersedia dengan definisi standar. Validator akan mendapatkan informasi dari off-chain (misalnya membuat panggilan api), menandatangani nilai dan kemudian mengumpulkan informasi tersebut dengan validator lain sebelum memasukkannya ke dalam rantai. Median dapat diterima sebagai nilai resmi dan langsung digunakan.   

Validator dapat memilih untuk mendukung tipe data yang lebih tidak jelas jika toleransi risikonya memungkinkan. Pengguna dapat melihat berapa persentase validator yang menandatangani/melaporkan setiap nilai. Jika minimal ⅔ validator melaporkan suatu data, data tersebut dapat dianggap selesai. Jika konsensus tidak mencapai ambang batas ⅔, nilainya masih dapat terbaca, namun harus dianggap “optimis” dan diambil dengan hati-hati. Data yang lebih berisiko harus memanfaatkan praktik terbaik seperti penerapan penundaan.

Tellor Layer akan memberikan keuntungan besar:

• Lebih banyak validator yang dapat memilih untuk menandatangani setiap bagian data
• Kontrak tata kelola khusus berdasarkan jenis kueri atau tata kelola modular

Perbedaan ini menyebabkan beberapa skenario pemotongan ketika nilai buruk dikirimkan:

1. Reporter dan validator dapat dipangkas berdasarkan konsensus validator lain
2. Pemotongan untuk tanda ganda (Validator Tellor Layer tidak dapat menandatangani data, mendorongnya ke rantai lain untuk dikonsumsi, dan tidak mengirimkannya ke Tellor Layer ( ini akan menjadi tanda ganda ) ) ¹
3. Pemotongan khusus melalui tata kelola modular (penyelesaian sengketa yang terkait dengan ID kueri).

 

Tata Kelola Modular

Dalam protokol Tellor lama, semua kueri menggunakan prosedur tata kelola yang sama. Namun dengan Tellor Layer, pengguna dapat memilih kerangka tata kelola yang paling sesuai dengan spesifikasi kueri mereka. Fleksibilitas ini diperlukan karena verifikasi beberapa pertanyaan dapat ditangani lebih cepat dibandingkan yang lain. Sedangkan validitas panggilan API mungkin dapat diputuskan dan dipilih dalam hitungan jam, berdasarkan kueri non-deterministik atau data subjektif dengan pengetahuan teknis tertentu…(misalnya menggunakan protokol Tellor untuk asuransi seperti dalam “apakah ini protokol diretas”) mungkin memerlukan waktu lebih lama. Dengan cara ini protokol Tellor dapat berfungsi sebagai mekanisme verifikasi yang cepat untuk ID tertentu, dan juga pengadilan yang terdesentralisasi dengan delegasi juri dan ahli teknis yang memberikan bukti dan penilaian.  

 

Data yang Didukung

Selain komitmen terhadap desentralisasi, protokol Tellor membedakannya dari oracle lain dengan menggunakan nilai data non-deterministik dan dengan membuat, melaporkan, dan memelihara rangkaian data yang kuat. Sifat non-deterministik dari arsitektur protokol Tellor memungkinkan kami memperluas dukungan ke laporan data subjektif yang lebih luas seperti data survei, spesifikasi kueri yang didefinisikan secara longgar, atau bahkan terus berkembang.

pertanyaan non-deterministik

Protokol Tellor bukan hanya API pembacaan middleware. Ada beberapa alasan mengapa kami enggan menyediakan akses ke API, yang utama adalah karena API tidak terdesentralisasi atau kuat untuk aplikasi. Misalnya, ketika pengguna menginginkan umpan harga (misalnya ETH/USD), Anda dapat meminta mereka untuk menyimpan daftar API yang sesuai dengan nilai yang mereka inginkan (misalnya coinbase, binance, coingecko api). Masalahnya adalah titik akhir ini dapat a) disensor oleh pihak hosting dan b) diubah (baik secara jahat atau hanya pembaruan versi rutin). Kami menemukan banyak protokol yang menginginkan desentralisasi penuh lebih memilih oracle (protokol Tellor) yang menangani proses tata kelola. Mereka jauh lebih terbuka untuk menerima kepemilikan oracle atas definisi “harga ETH yang valid” di mana konsensus reporter/oracle dapat memilih titik akhir mana yang akan dicapai.  

Mirip dengan struktur protokol Tellor saat ini, pengguna dapat memiliki spesifikasi data untuk queryId tertentu atau mengandalkan jaringan protokol Tellor untuk mengelola rangkaian yang kuat untuk kasus penggunaan tertentu (harga pasar wajar, harga penyelesaian eod, atau feed tahan manipulasi lainnya). Menggabungkan praktik terbaik dari penyelesaian keuangan tradisional atau perilaku harga likuidasi, serta pedoman pemotongan yang ditentukan pengguna, Tellor terus menetapkan standar di bidang defi, mendorong pengguna untuk menolak pendekatan dasar oracle yang hanya membaca api. 

laporan data subjektif

Protokol Tellor akan terus dapat digunakan untuk laporan subjektif yang luas termasuk titik akhir privat, interpretasi hukum subjektif, dan data survei yang terdesentralisasi. Untuk proyek-proyek seperti survei rumah tangga (misalnya CPI, pengangguran, dll.), persyaratan pertaruhannya bisa sangat rendah (banyak dari hal-hal ini sangat sulit untuk diverifikasi) dan outlier dapat ditangani pada tingkat agregat (mirip dengan praktik survei saat ini) . Protokol Tellor akan menangani data ini (on-chain atau melalui IPFS untuk kumpulan yang lebih besar) dan metodologi pelaporan untuk memungkinkan peralatan survei terdesentralisasi yang tidak dapat dipercaya (dan kemungkinan besar diberi insentif).  

Protokol Tellor tidak memaksa wartawan untuk mendukung semua data. Untuk oracle generik yang ideal, sistem harus mendukung data yang tidak diketahui atau perlu ditandatangani oleh semua orang (misalnya cuaca di lokasi tertentu, API berbayar, acara yang harus ada di sana, dll.). Tentu saja data menjadi lebih kuat ketika lebih banyak pihak dapat menyetujuinya, namun mengingat batasan peraturan dan berbagai lokasi global jaringan reporter, fleksibilitas adalah kunci untuk menciptakan oracle yang paling terdesentralisasi yang mampu menangani permintaan data apa pun. 

 

Keterbatasan MEV

Di Tellor Layer, pihak mana pun yang dipertaruhkan dapat menandatangani sebagian data tertentu dan MEV tidak lagi menjadi masalah. Validator mana pun yang ingin mengirimkan nilai untuk kueri tertentu dapat melakukannya. Perbedaan pembayaran antar validator hanya akan ada karena data mana yang didukung oleh masing-masing validator. 

 

Menggunakan Data Lapisan Tellor Pada Rantai Lain

Data Tellor Layer digunakan pada rantai lain dengan dua cara: metode pengambilan bukti negara dan pull oracle. Keduanya serupa dalam banyak hal, yaitu nilai-nilai akan diteruskan tanpa kepercayaan ke rantai lain untuk digunakan.  

 

Pengambilan Bukti Negara

Nilai pada Lapisan Tellor disusun menjadi bukti status (akar pohon merkle) yang dibuat oleh validator rantai. Rantai yang ingin menggunakan data Tellor Layer menjalankan klien ringan dari mekanisme konsensus Tellor Layer, memvalidasi bukti negara dengan mengamati tanda tangan validator untuk memperbarui bukti. Pihak yang ingin menggunakan data Oracle menggunakan bukti penyertaan ² untuk mereferensikan informasi dalam bukti negara.  

 

Tarik Oracle

Data yang dihasilkan oleh Tellor Layer dapat digunakan hampir secara instan setelah konsensus on-chain tercapai. Ini berfungsi dengan cara pengguna mengambil bukti konsensus dan nilai dari Tellor Layer menggunakan tanda tangan batch atau bukti zk. Bukti ini kemudian diteruskan dengan nilai ke rantai pengguna dan dapat digunakan segera setelah cukup banyak penandatangan yang memvalidasi data. Karena penandatanganan ganda dilarang, pengguna dapat yakin bahwa datanya aman. Untuk data yang lebih lambat atau kurang didukung (misalnya koin mikro, pengadilan terdesentralisasi, data survei), bukti negara adalah metode yang lebih hemat biaya. 

Ini hanyalah dua cara untuk membaca data dari Tellor Layer (klien ringan standar yang kami dukung), namun pendekatan lain kemungkinan akan mengambil alih dan membuat pendekatan kami tidak diperlukan (misalnya, dukungan yang lebih luas terhadap IBC ³ / XCM, atau data yang tidak dapat dipercaya atau dipercaya protokol jembatan ⁴ ).  

 

Keamanan Kustom

Pengguna akan dapat menambahkan keamanan tambahan dengan menambahkan persyaratan staking ke ID kueri. Dalam protokol Tellor saat ini, setiap pengiriman data hanya diberikan satu pasak. Namun, Lapisan Tellor akan memungkinkan pengguna membaca data lebih cepat jika lebih banyak validator menandatangani ID kueri tertentu. Misalnya untuk ETH/USD, harga yang relatif mudah diverifikasi dan didukung secara luas, pengguna dapat meminta 2/3 validator menandatangani data untuk setiap pengiriman. Jika konsensus tidak tercapai, penundaan 5 menit dapat ditambahkan untuk menunggu perselisihan, yang merupakan tanda bahwa pasar mungkin sedang bergejolak dan harga yang wajar untuk aset tersebut tidak tersedia. 

Perhatikan bahwa protokol yang menggunakan Protokol Tellor harus tetap menggunakan semua praktik terbaik termasuk standar data yang kuat dan bahkan fallback/tata kelola yang memerlukan konsensus sosial atau kontrol DAO dibandingkan jaminan ekonomi kripto. 

 

Forking dan peningkatan penanganan

Peningkatan bentuk yang lebih panjang pada kontrak jembatan dapat dilakukan melalui oracle itu sendiri. Dengan asumsi Anda memercayai oracle, peningkatan yang memerlukan percabangan dalam kontrak penghubung (misalnya perubahan dalam mekanisme konsensus atau serupa) dapat ditangani oleh oracle yang melaporkan kontrak penghubung yang valid pada setiap rantai yang terhubung. Saat pemutakhiran tertunda, pengembang dapat menerapkan kontrak validasi penghubung baru. Dengan memisahkan kontrak pembacaan data dan kontrak validasi, hal ini akan memungkinkan terjadinya peningkatan tanpa waktu henti.  

Masalah yang lebih sulit dalam menjembatani data adalah bagaimana sistem yang dijembatani dapat menangani fork. Meskipun fork sering dilihat sebagai sesuatu yang harus dihindari dengan cara apa pun (pandangan maxi btc), idealnya kita menggunakan fork sebagai penahan. Tellor menyadari bahwa lapisan subjektif terakhir adalah yang terbaik untuk mengamankan protokol-protokol ini (misalnya kita semua melihat ada sesuatu yang salah, mari kita lakukan fork). Masalahnya adalah Anda memerlukan cara di setiap rantai untuk memutuskan garpu mana yang sah. Untuk ini, sistem yang dijembatani dapat menggunakan mekanisme konsensusnya sendiri untuk menyelesaikan masalah ini, khususnya melalui permainan lapisan eskalasi/schelling dengan putaran tak terbatas yang diakhiri dengan lapisan subjektif dari protokol yang dijembatani itu ^sendiri5 .   Seiring dengan semakin matangnya Lapisan Tellor, masalah fork kemungkinan akan berkurang dan protokol harus memperketat keamanan ini atau menghapusnya sama sekali. 

 

Perubahan Tokenomics

Tidak ada, tetapi dapat mencetak token jika kenaikan gaji dijamin atau untuk insentif agar beralih ke mitra. Satu-satunya tindakan yang diperlukan adalah memindahkan hadiah berbasis waktu saat ini ke sistem baru (alamat oracle bata pada kontrak saat ini). 

Kontrak migrasi dua arah akan ada dari kontrak token Tellor saat ini ke kontrak jembatan Tellor Layer yang baru, sehingga memberikan waktu tak terbatas bagi bursa, reporter, dan pengguna untuk berpindah. Juga akan ada pencetakan token awal (jumlah tbd) untuk keamanan set validator bootstrap. 

 

Pertimbangan Filosofis untuk Desain dan Masa Depan

Membangun oracle generasi berikutnya memang sulit, namun masalah tersulitnya adalah memutuskan apakah kita ingin membangunnya atau tidak. Yaitu, kami ingin memastikan bahwa versi apa pun dari protokol Tellor sesuai dengan nilai-nilai kami dan pada saat yang sama dibuat agar tahan lama. 

Beberapa pertanyaan yang akan kami ingat saat kami membuat ini mencakup, namun tidak terbatas pada:  

• Apakah versi protokol Tellor ini menciptakan masa depan yang lebih adil, terdesentralisasi, dan/atau berkelanjutan?  

• Tujuan Tellor adalah masa depan dimana kebebasan ditingkatkan melalui desentralisasi dan kriptografi. Apakah protokol Tellor yang baru melakukan hal ini? 

• Dimana penangkapannya? Jika perlawanan terhadap sensor dan/atau desentralisasi gagal, di manakah hal ini akan terjadi dalam sistem ini? Apakah garpu sosial merupakan pilihan dengan struktur tertentu? 

• Apakah akan ada pengambilan node oleh institusi mana pun? 

• Apakah ada insentif/kemampuan yang tepat untuk menjalankan validator atau node secara solo? 

• Apakah sistem ini mengatasi CEX atau kontrol institusional atas token? 

• Apakah staking liquid diaktifkan/ada masalah?

• Bagaimana Tellor Layer dapat melampaui batasan satu rantai? Akankah rantai ini terisi juga? 

• Bisakah kita meluncurkan rantai/kontrak Oracle baru dan mengelompokkannya berdasarkan Tipe data (jembatan, dll.)

• Rollup rantai kami? Bukti lebih rekursif?

• Apakah kita hanya menambah ukuran blok? Gunakan lapisan DA untuk mengurai riwayat? 

 

Perlu diperhatikan, hal ini bukanlah sebuah pemecah masalah dan sulit bagi oracle mana pun, namun ini adalah masalah yang harus kita atasi dan pimpin ke depan. 

 

Alasan Pilihan Desain

Alasan terbesar kami memilih jalur ini adalah karena kami masih terlalu dini, dan kami tidak ingin menjadi penguji beta untuk produk penskalaan. Kami mendorong kemampuan Oracle, dan di situlah letak keahlian kami. Kami menginginkan sesuatu yang dapat berjalan secara realistis pada tahun depan tanpa terobosan dalam ilmu komputer atau pengorbanan total terhadap desentralisasi.  

 

Mengapa rantai kosmos?

Kami membutuhkan skala. Kami membutuhkan fleksibilitas.  

Opsi lain yang kami jelajahi adalah rollup SDK, menulis rantai kami sendiri, fork EVM, atau hanya kontrak pintar pada rantai/L2 yang lebih cepat. Setelah membandingkan tingkat kesulitan, umur panjang (keamanan hanya dibuktikan melalui produksi), dan biaya, Cosmos SDK menang. Ini adalah pilihan fleksibel dengan ekosistem kuat yang telah kami sukai selama bertahun-tahun. Selain SDK rantai dasar, kami dapat mendukung dompet, jembatan, bukti zk, dan banyak alat lain yang dibuat dan dikelola oleh tim lain. Kami ingin fokus pada penciptaan data terbaik, dan solusi ini memungkinkan hal tersebut. 

Jika pertanyaannya lebih berkaitan dengan “mengapa rantai kita sendiri” dibandingkan hanya membangun rantai seseorang, di sinilah kita memerlukan skala dan hasil yang lebih besar daripada yang dapat diberikan oleh opsi yang ada saat ini. Menjembatani menjadi lebih baik dan lebih mudah dan jika Anda berasumsi bahwa Anda memiliki dunia di mana hal ini dapat diselesaikan, menjalankan rantai terpisah bukan lagi kematian yang terisolasi seperti pada awal siklus terakhir. Kami membayangkan rantai aplikasi menjadi jembatan yang biasa dan tidak dapat dipercaya untuk melintasi berbagai hal. Ini adalah langkah pertama untuk mengakui visi tersebut. 

 

Mengapa bukan rollup?

Sejujurnya, ini adalah keputusan yang sulit. Kami memeriksa banyak struktur rollup saat ini (tumpukan OP, arbitrum, dll.) dan dua masalah yang kami temukan adalah a) struktur tersebut tidak terdesentralisasi sama sekali, dan b) terlalu mahal untuk memeriksa ke ETH. Karena kita perlu melakukan desentralisasi, hal ini bukanlah jalan yang bisa dilakukan. Kami ahli oracle, bukan arsitek gabungan. Ada opsi lain yang akan segera hadir (zk rollup, zkEVM, celestia, dll.), namun menurut kami ini masih terlalu dini untuk dapat digunakan dengan cara yang terdesentralisasi kapan saja selama beberapa tahun ke depan. Belum lagi, sebagai oracle, kita memerlukan finalitas yang lebih cepat daripada kebanyakan L2 saat ini agar dapat digunakan di semua rantai. Kita dapat mencapai hal ini dengan L1, tapi sayangnya ada trade-off antara kecepatan rollup dan biaya (karena seberapa sering Anda melakukan checkpoint). Kami mungkin masih menempuh jalur keamanan bersama dalam beberapa cara, dan juga melihat banyak desain oleh tim untuk mendapatkan konsensus plug and play untuk menjadi rollup / rantai Anda sendiri secara dinamis, semuanya dari Cosmos SDK. Jika biaya turun, opsi terdesentralisasi tersedia, dan penyelesaian menjadi lebih cepat, kami pasti akan tetap membuka opsi ini.  

 

Kesimpulan

Versi protokol Tellor berikutnya masih dalam pengembangan. Hal ini memberikan gambaran umum tentang arah yang kami tuju, namun umpan balik, diskusi, dan kritik dihargai dan didorong!  Hubungi kami jika Anda ingin terlibat, berpotensi menggunakan protokol Tellor, atau hanya ingin mengobrol tentang desain Oracle.  

Share: