BARU: Helius mengakuisisi Light Protocol
Roket, Ancaman Kuantum, Nol dan Satu: Dean Little tentang Menempa Kebenaran Solana
Blog/Budaya

Roket, Ancaman Kuantum, Nol dan Satu: Dean Little tentang Menempa Kebenaran Solana

Developer Experience Engineer0xIchigo di X0xIchigo di LinkedIn0xIchigo di GitHub
Bacaan 28 menit

Pendahuluan

Blockchain dibangun di atas kebohongan. Tepatnya, kebohongan yang halus, yang terwujud dalam lapisan-lapisan abstraksi. Ada dunia yang dilihat developer, penuh dengan SDK, API, dan framework yang menjanjikan kecepatan serta keamanan. Kenyataannya jauh lebih bernuansa, dipenuhi register, syscall, dan bytecode—sebuah realitas yang hanya berani dimasuki orang-orang nekat. Faktanya, setiap abstraksi menimbulkan overhead, dan setiap compiler menyembunyikan kebenaran.

Dean Little menghabiskan kariernya menavigasi kebohongan ini, mencari kebenaran dengan menyolder sirkuit dan mem-flash EEPROM. Bersama Bitcoin, ia membangun mining pool, kernel GPU, dan tooling SPV, sedekat mungkin dengan mesin, sembari mempelajari potensi sistem terdistribusi yang saat itu belum benar-benar mampu diwujudkan. Lalu, ia menemukan Solana, tempat ia dikenal karena pemikirannya yang dianggap sesat: menulis assembly secara manual, meremehkan compiler, dan menyalahgunakan syscall—bukan karena itu menyenangkan, melainkan karena kecepatan adalah kebenaran.

Sebagai Chief Scientist di Zeus Network, ia mengimplementasikan seluruh protokol Bitcoin dari nol di atas Solana, memungkinkan likuiditas BTC mengalir tanpa hambatan. Dan, sebagai unjuk kemampuan yang kebal terhadap troll untuk melawan FUD kuantum, ia merekayasa vault Winternitz One-Time Signature yang mampu memigrasikan puluhan ribu aset per detik, sementara yang lain baru bisa bermimpi mencapai enam. 

Namun, Dean juga seorang pengajar. Dari Turbin3 hingga Blueshift dan pekerjaan terbarunya sebagai DevRel untuk tim Pasar Bahasa Mandarin dan Kanton di Solana Foundation, ia membawa developer memasuki dunia yang tak akan pernah dilihat sebagian besar orang. Ia telah mengajari ratusan developer untuk meluncurkan produk on-chain, sering kali dalam bahasa mereka sendiri dan dimulai dari nol. Ketegangan yang ia hadapi selalu sama: menarik orang naik dengan abstraksi, lalu mendorong mereka turun mendekati mesin. 

Saya ingin memahami arti hidup dalam ketegangan ini—antara edukasi dan eksperimen, abstraksi dan assembly, menulis kode untuk manusia dan menulis instruksi untuk mesin. Wawancara ini membahas dialog tersebut dan arti berbicara langsung kepada mesin ketika semua orang lain justru tidak benar-benar berkomunikasi dengannya.

Percakapan ini telah diedit dan diringkas agar lebih singkat. 


Wawancara

Awal Perjalanan dan Pandangan Dunia

Anda tidak boleh begitu saja menerima batasan. Anda harus melawannya dengan cara-cara kreatif yang belum terpikirkan orang lain. Itulah filosofi yang saya bawa ke dalam pekerjaan saya di Solana.

Dean Little
Dean Little
Penyalahguna Syscall, Kucing Kuantum, Kurator @ Blueshift

Ichigo: Jauh sebelum Solana, Anda memperbaiki hardware, mem-flash EEPROM, dan menulis sistem kontrol tertanam untuk roket. Bagaimana bekerja begitu dekat dengan mesin—secara harfiah menggunakan solder dan firmware—membentuk pandangan Anda sebagai builder?

Dean Little: Saya belajar menyolder saat berusia sekitar sepuluh tahun. Saya tumbuh dengan mengutak-atik mikroprosesor dan mikrokontroler, lalu beralih ke pengembangan web dan seluler sebelum akhirnya bergabung dengan startup roket di Norwegia.

Bekerja pada sistem tertanam yang sangat penting bagi misi mengajarkan beberapa hal yang benar-benar penting. Pertama, perhatian terhadap detail—karena jika sesuatu gagal, keadaan dapat memburuk dengan sangat cepat. Kedua, kesederhanaan: sistem yang sederhana, cepat, dan mudah dipahami biasanya lebih baik daripada sistem yang terlalu rumit. Ketiga, Anda belajar berpikir secara adversarial. 

Bagi saya, mengerjakan kontrol ballast untuk peroketan samudra berarti terus bertanya: apa yang terjadi jika pengontrol ini gagal? Bagaimana kami mendeteksi kegagalan? Cadangan apa yang kami miliki? Bagaimana jika kontrol sikap kami keliru dan kami mengira sedang mengarah ke atas, padahal sebenarnya mengarah ke bawah? Ini memaksa Anda merancang sistem untuk menghadapi kegagalan, bukan berasumsi semuanya akan selalu berfungsi.

Hal lain yang Anda pelajari adalah tidak memercayai pekerjaan orang lain secara membabi buta. Ini berlaku untuk software maupun hardware. Produsen hardware mengubah spesifikasi, bagian pengadaan mungkin tidak sengaja membeli komponen yang salah, dan tiba-tiba tidak ada yang berfungsi. Begitu banyak hal dapat bermasalah, dan hanya perlu satu kesalahan kecil untuk membuat seluruh sistem gagal. Pola pikir itu terus melekat pada diri saya sejak saat itu. 

Dari sana, karier Anda dengan cepat membawa Anda ke Bitcoin. Anda mengerjakan mining pool, kernel GPU, tooling SPV, dan kemudian Twetch. Apa yang diajarkan tahun-tahun mengerjakan infrastruktur Bitcoin tersebut tentang membangun sistem terdistribusi dalam skala besar dan tentang keterbatasan blockchain pada saat itu?

Saya mulai bekerja penuh waktu dalam pengembangan Bitcoin sekitar tahun 2017. Saya membangun di berbagai blockchain—Bitcoin, EOS, dan beberapa lainnya yang populer saat itu. Dengan Bitcoin, awalnya saya hanya menggunakannya, tetapi ketika biayanya melonjak sangat tinggi, Bitcoin praktis tidak dapat digunakan. Itulah gelombang besar pertama pengguna ritel yang masuk ke crypto, dan saat itu saya menyadari bahwa begitu biaya melonjak, blockchain menjadi tidak berguna.

Pengalaman itu membuat saya memikirkan kembali apa yang disebut “trilema skalabilitas.” Sejujurnya, itu masalah omong kosong yang dibuat-buat. Bahkan pada tahun 2017, kita dapat mengirim foto berukuran 4MB ke seluruh dunia dalam waktu kurang dari satu detik. Rasanya konyol memercayai bahwa blockchain tidak dapat berkembang melampaui blok 1MB. Batasannya bukan fisika—melainkan desain. 

Karena base layer Bitcoin sangat terbatas, Anda terpaksa berinovasi dengan cara lain. Saya akhirnya mendalami Secp256k1 dan membangun solusi untuk menyembunyikan hasil eksekusi dalam signature. Itu semacam komputasi terverifikasi yang masih kasar, jauh sebelum ZK benar-benar mulai berkembang pesat.

Tahun-tahun tersebut mengajari saya bahwa menjalankan perusahaan Bitcoin sebenarnya berarti menjalankan perusahaan infrastruktur. Protokol Bitcoin dapat melakukan banyak hal, tetapi software node-nya terbatas. Model UTXO sangat bagus untuk paralelisasi karena state-nya terpisah, mirip seperti account Solana, tetapi buruk untuk shared state dan pengindeksan. Di sisi lain, model account Ethereum sangat bagus untuk shared state, tetapi buruk untuk paralelisasi. Hal yang membuat saya tertarik pada Solana adalah model account terpisahnya—model ini menggabungkan paralelisasi UTXO dengan kemudahan penggunaan model global state Ethereum.

Pelajaran terbesar saya dari tahun-tahun itu adalah bahwa sistem sering kali gagal. Karena itu, sistem seharusnya dirancang agar dapat gagal secara terkendali, bukan secara katastrofik. Anda tidak boleh begitu saja menerima batasan. Anda harus melawannya dengan cara-cara kreatif yang belum terpikirkan orang lain. Itulah filosofi yang saya bawa ke dalam pekerjaan saya di Solana.

Kini, banyak orang di komunitas Solana mengenal Anda sebagai sosok yang menulis assembly dan meremehkan compiler. Mengapa tetap begitu dekat dengan mesin? Mengapa tidak lebih berfokus meningkatkan abstraksi tingkat tinggi karena sebagian besar developer akan membangun di sana?

Berlawanan dengan anggapan umum, saya adalah kontributor untuk Anchor, Pinocchio, Agave, Alpenglow—pada dasarnya semuanya. Saya telah mengerjakan kriptografi, SIMD, dan program tingkat rendah di seluruh stack. 

Hal terbesar dalam pengembangan Solana adalah bahwa segala sesuatu di luar program on-chain dan infrastruktur sepenuhnya memerlukan izin. Hampir mustahil bagi saya untuk membuat PR saya digabungkan ke repo resmi mana pun. Namun, program on-chain? Saya dapat melakukan apa pun yang secara tidak sengaja diizinkan oleh sistem. Tidak ada yang menghambat saya di sana. Semuanya permissionless. Saya dapat terus membuatnya lebih baik dan tampil luar biasa.

Jadi pertanyaannya, jika Anda melihat pekerjaan saya, kualitasnya, serta apa yang telah saya lakukan untuk program on-chain, dan Anda ingin hal yang sama terjadi pada lapisan stack lainnya, mulailah menggabungkan PR saya, haha.

Untuk urusan assembly, terus terang, compiler bekerja dengan buruk, dan orang-orang yang mengerjakannya pun tidak jauh lebih baik. Mereka tidak pernah meluangkan waktu untuk benar-benar mendengarkan pelanggan akhir mereka, yaitu developer. Itulah sebabnya kami harus membuat toolchain independen sendiri agar hidup kami lebih mudah.

Sayangnya, sebagian besar developer agak biasa saja. Bukan dalam arti buruk, tetapi mereka tidak seperti Cavey, saya, atau para jagoan Ellipsis DeFi yang benar-benar tahu cara menulis sesuatu dengan performa sangat tinggi. Kami adalah subset kecil developer yang agak unik, yang tahu cara mendorong batas sistem pada level terendah dan membuatnya lebih baik untuk digunakan semua orang. 

Masukan kami bisa sangat berharga, tetapi sering kali tidak dianggap serius. Jadi, pada akhirnya kami hanya berinovasi pada hal-hal yang tak dapat dilarang siapa pun untuk kami sentuh—yaitu VM. Karena itulah saya tetap dekat dengan mesin dalam konteks tersebut. 

Inovasi dan Kontribusi Teknis

Berbicara tentang bekerja di berbagai bagian stack—antara Zeus, Jupiter, dan waktu luang Anda sendiri—Anda telah membangun dan mengintegrasikan beberapa primitive kriptografi tingkat lanjut. Membangun segala jenis kriptografi on-chain memang dikenal sulit di Solana. Seperti apa masa depan kriptografi di Solana? Dan, selain meneriaki orang agar menggabungkan PR, haha, bagaimana kita mempermudah orang lain membangun primitive yang lebih canggih?

Menurut saya, beberapa tahun lalu, ada banyak tim ZK yang siap membangun di Solana. Pada dasarnya, kami berkata kepada mereka, “Ya, itu akan segera hadir,” lalu Firedancer muncul dan berkata, “Tidak, kami tidak akan menggabungkan ini,” sehingga semuanya terus tertunda. Beberapa tim tersebut telah menggalang pendanaan dan benar-benar tidak dapat menjalankan bisnis karena tidak memiliki primitive kriptografi on-chain yang diperlukan, sehingga mereka terpaksa pergi ke tempat lain. Itu sangat berat. Memperlakukan developer seperti itu adalah tindakan yang salah. Pelanggan utama protokol adalah developer—jika Anda tidak memperhatikan mereka, tidak ada yang akan dibangun, dan pengguna ritel pun tidak punya apa pun untuk digunakan. 

Jadi saya berkata, baiklah, saya akan mencari solusinya sendiri. Saya mengutak-atik syscall recover Secp256k1 dan pada dasarnya melakukan jailbreak terhadap seluruh curve. Kini Anda dapat menggunakan signature Schnorr, commitment Pedersen, Bulletproofs, perkalian elliptic curve arbitrer, bahkan alamat Taproot yang dimodifikasi, semuanya tanpa satu pun perubahan protokol dan hanya dengan biaya sekitar 25.000 CU. Itu dilakukan satu orang pada waktu luangnya. Saya telah meluncurkan lebih banyak protokol kriptografi daripada Anza, bukan? Bayangkan apa yang dapat terjadi jika hal ini benar-benar didorong. Bayangkan jika pengembangan lebih terbuka. 

Hal lucunya, sebagian besar orang bahkan tidak menyadari betapa besarnya terobosan ini. Saya akan menghadiri konferensi dan menceritakan apa yang saya bangun kepada beberapa orang dari Arcium. Mereka akan berkata, “Itu keren sekali.” Namun, selain mungkin sepuluh orang di antara kami yang benar-benar memahami kripto(grafi) pada level tersebut di Solana, tidak ada yang benar-benar menyadarinya. 

Tentang Anza—mereka orang-orang baik, tetapi hanya memiliki satu kriptografer, Sam Kim. Walaupun ia cukup ahli, menurut saya fakta bahwa tidak ada orang lain di Anza yang memahami kriptografi merupakan sinyal yang cukup bearish. Mereka melibatkan saya sebagai reviewer untuk upgrade Alpenglow. Saya meninjau kode Sam, dan sebagian besar kodenya bagus serta idenya masuk akal. Saya rasa bagus bahwa mereka menerima dan memanfaatkan keahlian orang lain. Namun, pada akhirnya, Anza mungkin tidak akan pernah benar-benar hebat dalam hal ini. Anda memerlukan beberapa perusahaan yang saling bersaing, masing-masing memiliki beberapa bidang yang tumpang tindih sekaligus spesialisasi sendiri. Tidak masuk akal jika Anza mencoba melakukan semuanya. Diversifikasi pengembangan inti adalah hal yang benar-benar kita perlukan.

Menurut Anda, apakah ini lebih merupakan masalah budaya? Misalnya, Ethereum memiliki sejumlah L2 yang sepenuhnya didedikasikan untuk ZK, seperti ZKsync atau StarkWare. Apakah Solana menganggap teknologi ZK hanya sebagai gagasan skalabilitas yang samar? Seolah kita lebih memilih memaksimalkan hardware, sehingga itulah fokus utama kita—kita akan menskalakan chain dengan cara tersebut. Dan meskipun penggunaan ZK di Solana sebenarnya tidak harus terbatas pada skalabilitas, ZK telanjur dianggap demikian dan kini berada dalam posisi yang aneh?

Menurut saya, tooling-nya tidak bagus. Sama sekali tidak ada tutorial tentang cara menggunakannya. Blueshift akan menambahkan beberapa—kami hanya sedang mencoba menggabungkan fitur SIMD Little Endian. Setelah itu digabungkan, kami akan merilis template ZK yang mudah digunakan dan berperforma sangat tinggi, serta beberapa tutorial, karena kami ingin mempermudah orang membangun sesuatu dan memahami cara kerjanya.

Masalahnya saat ini, perjalanan dari nol hingga Hello, World! di Solana benar-benar tidak masuk akal. Misalnya, jika Anda melihat Sui dan mengikuti dokumentasinya selama lima menit, Anda akan memiliki Hello, World! yang berfungsi. Solana tidak memilikinya. Jadi, itulah perbedaan antara Mysten Labs yang mempekerjakan sekitar 10 orang yang memahami kriptografi dan Anza yang mempekerjakan satu orang, bukan?

Menurut saya, ada anggapan bahwa Solana Foundation sangat kekurangan pemahaman teknis tentang, ya, apa pun. Konsep teknologi mereka hanya menjangkau komersialisasi, bukan? Di luar itu, mereka menyerahkan tugas memikirkan hal-hal tersebut kepada Anza. Gagasannya adalah jika jawabannya mengatakan sesuatu itu bagus, maka itu pasti bagus. Kenyataannya, sering kali jawabannya bagus dari sisi performa, tetapi tidak terlalu bagus dalam hal lainnya.

Solana Foundation beranggapan bahwa semuanya berjalan sangat baik. Namun, pengalaman developer justru seperti, “Ini sulit digunakan.” Ini sangat menyakitkan bagi orang-orang yang lebih ahli daripada mereka yang mengimplementasikan sesuatu di level protokol, yang melakukan pekerjaan sukarela, tetapi karyanya tidak dianggap serius. Seolah-olah, “Oh, entahlah, mereka tidak punya lencana ajaib Anza. Abaikan saja mereka dan hindari risiko reputasi atau penggabungan PR komunitas.” Jadi, mungkin itulah sebabnya Anda melihat saya berjuang keras dan sering membela developer open source—agar kita dapat menyingkirkan masalah ini, karena menurut saya ada banyak orang di komunitas yang mengirimkan PR berkualitas tinggi. Memang ada banyak sampah AI dan banyak hal buruk, tetapi ada pula banyak orang hebat yang layak mendapat perhatian. Ini adalah blockchain, sebuah jaringan terdistribusi—kita seharusnya tidak memerlukan semacam lencana Anza untuk berkontribusi. Mereka seharusnya bertanggung jawab memperhatikan kode yang bagus, terlepas dari siapa yang menulisnya.

Terlepas dari semua ini, berbicara lebih jauh tentang inovasi dan sisi kriptografi, Anda juga membangun vault tahan kuantum di Solana menggunakan Winternitz One-Time Signatures. Apa yang menginspirasi proyek tersebut, dan bagaimana Anda melihatnya berkembang pada masa mendatang, mungkin ketika ancaman kuantum menjadi lebih nyata?

Sejujurnya, semuanya bermula dari sebuah tweet, haha. Seorang maksimalis Bitcoin menulis pada akhir tahun lalu, “Solana akan menjadi korban pertama kuantum.” Saya membacanya dan berpikir, “Baiklah, bro. Jika kita perlu memigrasikan orang dari kriptografi yang tidak aman terhadap kuantum ke kriptografi yang aman terhadap kuantum, chain kami dapat menangani lebih dari 50.000 migrasi per detik. Chain Anda hanya sekitar enam. Siapa yang sebenarnya akan hancur lebih dulu?”

Jadi saya berkata, persetan, saya akan mewujudkannya. 

Sepuluh hari kemudian, saya merilis Winternitz vault dan mengutip tweet-nya dengan komentar: GG. 

Itulah motivasinya—seseorang mengatakan bahwa itu tidak dapat dilakukan. Saya sudah cukup lama memikirkan skema signature pascakuantum, tetapi hal itu mendorong saya untuk benar-benar melakukannya.

Dan itu berhasil. Anda dapat menyimpan dana dalam PDA yang bersifat off-curve, menggunakan Winternitz vault, dan apa pun yang terjadi—baik ledger di-rollback maupun serangan kuantum mengacaukan signature leader—setidaknya dana Anda akan tetap aman dalam versi mana pun yang menjadi tujuan rollback. Ini bukan solusi mutlak, tetapi merupakan sekoci penyelamat yang sempurna. 

Jika Anda adalah pengelola dana yang menyimpan jutaan atau miliaran dalam LST atau SOL yang di-staking, lalu tiba-tiba keamanan kuantum menjadi persyaratan regulasi, ini tidak lagi menjadi penghambat adopsi. Anda tidak memerlukan upgrade protokol. Semuanya langsung berfungsi.

Saat ini, saya telah membuat firmware Ledger yang menandatangani signature ini, beserta wallet dan aplikasi web. Blueshift mungkin akan berupaya mengubahnya menjadi sesuatu yang lebih ramah pengguna pada akhir tahun ini. Jelas ini belum mendesak, tetapi intinya: opsi tersebut sudah tersedia saat ini. Itulah terobosannya.

Sebenarnya ini sangat lucu. Toly mengirim DM kepada saya keesokan harinya. Dengan bercanda, ia berkata, “Bro, saya kira ketika komputer kuantum muncul, saya harus diam-diam pensiun.” Saya menjawab, “Haha, jangan pensiun, bro. Kami siap membantu Anda.”

Berbicara tentang Bitcoin, Anda adalah Chief Scientist di Zeus Network, tempat Anda pada dasarnya mengimplementasikan seluruh protokol Bitcoin dari nol di atas Solana. Apa tantangan terbesar untuk mencapainya? Dan apakah Anda melihat masa depan ketika chain lain diimplementasikan ulang di atas Solana?

Itu pertanyaan yang sangat menarik. Sama seperti signature Winternitz yang membutuhkan komputasi sangat besar, tetapi masih dapat dilakukan meski nyaris mencapai batas dalam satu transaksi, Bitcoin juga berada di titik ideal yang sama. Bitcoin cukup canggih sehingga kita dapat memiliki hal-hal seperti proof SPV, tetapi masih cukup primitif sehingga Solana, sebagai platform yang lebih canggih dan berperforma tinggi, dapat mengambil hal tersebut dan memasukkannya ke dalam hal ini.

Dengan blockchain generasi kedua seperti Ethereum, hal ini lebih rumit. Blockchain tersebut jauh lebih tidak primitif dan jauh lebih kompleks. Jadi pertanyaannya menjadi: dapatkah Solana terus menjadi lebih cepat sembari mengalokasikan semakin banyak resource untuk satu transaksi? 

Saat ini, hal tersebut masih sulit, meski bukan mustahil. Hal utama yang belum tersedia untuk kompatibilitas EVM saat ini adalah syscall BigModExp. Jika kita mengaktifkannya, saya rasa kita dapat mendekati paritas penuh dengan Ethereum pada level VM, dan itu cukup gila untuk dipikirkan. 

Namun, pertanyaan yang lebih besar adalah: untuk apa bersusah payah? 

Untuk Bitcoin, jawabannya jelas: nilainya mencapai triliunan, menjadi standar emas untuk uang, dan cukup primitif sehingga Solana dapat mereplikasinya dengan baik. 

Ethereum? Tidak terlalu. 

“Uang ultrasound” adalah meme. Untuk sesaat, anggaran keamanan Solana bahkan melampaui Ethereum. Jadi, apakah itu menjadikan Solana uang ultrasound? Membungkus ETH ke Solana tidak memberikan nilai sebanyak membungkus BTC.

Jadi, ya, menurut saya Bitcoin adalah target pertama yang tepat. Secara teknis dapat dilakukan dan secara ekonomi bermakna. Seiring Solana terus berkembang, kita mungkin akhirnya melihat chain lain turut diimplementasikan ulang. Namun sejujurnya, semakin tinggi performa Solana, semakin kecil pula kebutuhan untuk bersusah payah dengan chain lain.

Kemampuan mengemas seluruh fungsionalitas ini ke dalam satu transaksi sangat menarik. Baru-baru ini, Anda terpancing untuk mendalami update oracle ultraefisien, mendorong batas dengan Doppler dan update 21 CU miliknya. Bagaimana pencapaian dengan CU rendah ini menunjukkan keunggulan Solana dibandingkan chain lain? Kita telah melihat perkembangan serupa di chain lain melalui gas golfing, tetapi apa saja peluang unik yang terbuka di Solana?

Oracle merupakan studi kasus yang sangat menarik karena semua orang cenderung menganggapnya sudah “terpecahkan.” 

Jika melihat kembali sekitar sebulan lalu, Cavey menggunakan program noop saya dan mencapai 100.000 transaksi per detik di mainnet. Itu keren. Sekarang, kami akan melihat apakah angka itu dapat didorong lebih jauh. Lebih spesifiknya, 100.000 update oracle per detik di mainnet. 

Jika itu memungkinkan, seluruh narasi “kita memerlukan waktu blok yang lebih cepat untuk bersaing dengan Binance” akan runtuh sepenuhnya. Jika Anda dapat memperbarui oracle seratus ribu kali per detik, siapa yang peduli dengan update Binance setiap 20 milidetik?

Itulah inti hyper-optimization. Prop AMM sebenarnya sudah menggunakan gaya update seperti ini—tidak persis sama dengan yang saya publikasikan, tetapi jika Anda tahu, Anda tahu. Saat ini, mereka menanamkan logika tersebut jauh di dalam strategi trading mereka. 

Dengan Doppler, tidak ada banyak alasan untuk mempertahankan kompleksitas tersebut di dalam program mereka. Update oracle dapat sepenuhnya dipisahkan dan dijalankan sendiri.

Jejaknya juga sangat kecil. Oracle Doppler hanya berukuran sekitar 480 byte. Saya bahkan sedang mengembangkan SDK TypeScript agar developer dapat men-deploy versi kustom mereka sendiri langsung dari TypeScript tanpa perlu menyentuh Rust. Anda cukup mendefinisikan skema Borsh, memublikasikannya, lalu mulai menghantamkan update oracle dengan kecepatan penuh. Tentu saja, developer Rust dapat melakukan hal yang sama, tetapi menurut saya menarik bahwa kini developer TypeScript pun dapat mengakses tingkat performa tersebut dengan assembly yang sangat dioptimalkan di balik layar.

Untuk use case: oracle keacakan, perpetual, AMM oracle, prop AMM—semuanya mendapatkan manfaat. Begitu pula hal-hal seperti channel pembayaran atau penskalaan L2. Jika Anda dapat membuka dan menutup channel dengan biaya praktis nol, dampaknya sangat besar. Pada dasarnya, Anda tidak lagi memerlukan program Anchor raksasa yang berlebihan hanya untuk memperbarui oracle. 

Abstraksi, Assembly, dan IBRL

Kami ingin merangkul orang pada level apa pun dan terus menggeser mereka ke kanan. Blueshift, Solana Foundation—tujuannya sama.

Dean Little
Dean Little
Penyalahguna Syscall, Kucing Kuantum, Kurator @ Blueshift

Mengingat reputasi Anda dalam menulis assembly, menurut Anda apakah sebagian besar developer perlu benar-benar menyentuhnya? Atau apakah ini salah satu hal yang batasnya hanya perlu didorong oleh segelintir orang agar yang lain dapat membangun dengan aman di tingkat stack yang lebih tinggi?

Menurut saya, semua orang harus mempelajarinya, setidaknya sedikit. George Hotz, mungkin programmer terbaik yang masih hidup, pernah mengatakan bahwa semua orang harus mempelajari Python, C, dan assembly. 

Jika tidak memahami assembly, Anda tidak memahami apa yang sebenarnya dilakukan compiler. Jika tidak memahami C, Anda tidak akan menghargai semua kemudahan yang diberikan Python. Menurut saya Python tidak terlalu hebat, tetapi Rust, misalnya, adalah bahasa yang sangat ekspresif dan dapat digunakan pada level tinggi maupun rendah. Rust merupakan pilihan yang sangat baik.

Jadi, ya, saya sarankan mempelajari sedikit assembly dan Rust. Pada suatu saat, Anda juga perlu mempelajari TypeScript jika ingin menulis frontend. Pada akhirnya, Anda membangun produk untuk manusia. Jika pengguna Anda adalah developer, TypeScript akan muncul di radar Anda, suka atau tidak.

Ketika pertama kali mulai menulis assembly di Solana, benar-benar tidak ada yang melakukannya. Saya kemudian membangun tooling, menerbitkan beberapa contoh, dan kini ada beberapa ratus orang yang telah mencobanya. Mungkin sekitar sepuluh orang benar-benar ahli. Beberapa bahkan telah menulis program yang lebih mengesankan daripada program saya. Sebagian besar hanya soal meluangkan waktu untuk mewujudkannya.

Sebagian besar yang saya kerjakan adalah hal kecil, elegan, berperforma sangat tinggi, dan memiliki satu tujuan—area yang menurut saya berpotensi meningkatkan efisiensi biaya eksekusi hingga 100 kali lipat. Peran saya lebih berfokus pada eksplorasi, menginspirasi, dan membiarkan orang lain mengembangkannya lebih jauh. Pada tahap ini, saya tidak mendapat banyak manfaat dengan terus mempromosikan semua yang saya bangun. Jadi, saya lebih memilih menyoroti karya orang lain, me-retweet mereka, dan membantu mereka membangun nama.

Jadi, ya, menurut saya semua orang setidaknya harus mempelajari assembly. Ini latihan yang sangat baik. Namun, pada saat yang sama, segelintir orang yang berupaya keras pada level terendah juga dapat menciptakan peningkatan yang bermanfaat bagi semua orang. 

Jika Anda melihat sebagian besar peningkatan yang terjadi pada Pinocchio dalam enam bulan terakhir, semuanya berasal dari optimasi assembly. Febo telah melakukan triase terhadap setiap PR layaknya seorang jagoan sejati dan berhasil menggabungkan beberapa hal yang sangat bagus. Misalnya, lihat p-token—konsepnya sama. 

Apakah Anda memandang coding tingkat rendah bukan hanya sebagai pilihan teknis, tetapi mungkin juga sebagai sesuatu yang lebih ideologis?

Ya, menurut saya keduanya. Misalnya, mengapa orang ingin menaruh JPEG di Bitcoin? Ada sesuatu yang primitif dan menarik secara intrinsik ketika sistem yang sangat terbatas ini digunakan untuk sesuatu yang tidak pernah dirancang untuk dilakukannya. Ini cukup lucu, sekaligus indah. 

Rasa ingin tahu berakhir ketika Anda berhenti bertanya. 

Jadi, jika Anda orang yang penuh rasa ingin tahu, titik akhir yang logis dari rasa ingin tahu Anda mungkin seperti, “Saya menulis sesuatu dalam TypeScript yang menggunakan program Anchor. Bagaimana cara kerja Anchor? Bagaimana cara kerja macro? Bagaimana cara kerja Rust? Bagaimana cara kerja assembly?” 

Mungkin kemudian Anda mulai mendalami compiler Rust, lalu MIR, LLVM IR, dan bagaimana semuanya dikompilasi menjadi eBPF. Lalu Anda bertanya apa itu eBPF dan membaca tentang assembly-nya. Akhirnya, Anda menatap bytecode mentah dan menyadari bahwa Anda dapat memangkas beberapa byte karena compiler tidak mengoptimalkan sesuatu secara otomatis. Itulah titik akhir logis dari penyelidikan tersebut. Jelas ada aspek ideologis di dalamnya.

Anda juga bekerja dengan Solana Foundation untuk membantu tim berbahasa Mandarin dan Kanton memulai, melakukan debug, dan membangun. Anda bekerja dengan semua tim ini dan membantu mereka dengan membuat berbagai hal menjadi lebih sederhana serta mudah diakses. Pada saat yang sama, Anda dikenal sebagai pendukung assembly dan penyalahgunaan syscall. Bagaimana Anda menyelaraskan ketegangan tersebut? Bagaimana Anda menyeimbangkan dorongan agar developer lebih dekat dengan mesin dengan kebutuhan praktis untuk membantu mereka memulai melalui abstraksi tingkat tinggi?

Jika melihat Blueshift, pada dasarnya kami telah merancang sebuah spektrum dari pemula hingga ahli. Pandangan saya sederhana: Anda mendapatkan level developer sesuai dengan level pelatihan yang Anda berikan. Jika Anda hanya mengajarkan Anchor atau TypeScript, Anda hanya akan menarik jenis developer yang menganggap itu sudah cukup. Namun, jika mulai membahas pemangkasan satu demi satu compute unit dengan assembly buatan tangan, Anda akan menarik developer dengan kaliber berbeda—orang-orang yang benar-benar memahami arti kata-kata tersebut.

Strategi Blueshift adalah membidik bagian tengah kurva terlebih dahulu. Di situlah jumlah orang terbanyak dan ROI terbaik dapat diperoleh. Kemudian kami menggeser mereka ke kanan, membantu mereka meningkatkan kemampuan, hingga akhirnya Anda memiliki pasukan developer tangguh yang dapat berbalik dan mendukung sisi kiri kurva—para pemula sejati.

Cara itu lebih mudah diskalakan. Saya dapat menghabiskan berjam-jam setiap hari untuk mengajari pemula melakukan CPI ke Token Program, yang mencakup 90% dari seluruh program Solana. Atau saya dapat melatih seratus orang untuk melakukan hal yang sama, lalu masing-masing membantu seratus orang lain memulai. Begitulah cara Anda menskalakannya. 

Kami ingin merangkul orang pada level apa pun dan terus menggeser mereka ke kanan. Blueshift, Solana Foundation—tujuannya sama.

Edukasi, Transfer Pengetahuan, dan Komunitas

Berbicara tentang Blueshift, Anda ikut mendirikannya bersama Turbin3, yang keduanya memiliki misi edukasi kuat. Ke mana arah inisiatif-inisiatif ini pada masa mendatang? 

Saat saya bergabung, Turbin3 belum memiliki banyak hal. Saya masuk, menulis semua program dalam kurikulumnya, dan mulai menjalankan berbagai kegiatan. Saya rasa saya menangani tiga atau empat cohort dan melatih semua orang yang kini menjadi pengajar. Dalam sembilan bulan, kami berubah dari tidak memiliki apa pun menjadi mampu menggantikan saya melalui pelatihan yang baik, sehingga tidak banyak lagi yang perlu saya lakukan. Melatih orang melalui pelatihan berkualitas menunjukkan adanya efek flywheel yang dapat diskalakan.

Masalahnya, mereka menerima seribu pendaftaran setiap kuartal dan menolak sekitar 800 hingga 900 orang. Mereka yang diterima mengikuti kursus selama enam minggu dan harus menghadiri kelas tiga kali seminggu. Pada akhirnya, mereka tidak memperoleh sertifikat atau apa pun yang membuktikan kelulusan—mungkin pihak penyelenggara akan memberikan rekomendasi, mungkin juga tidak. Namun, enam minggu adalah waktu yang panjang untuk berharap tidak ada masalah dalam hidup Anda. Anjing Anda bisa sakit sehingga Anda harus membawanya ke dokter hewan dan melewatkan beberapa kelas. Tiba-tiba Anda tertinggal dan dikeluarkan. Bootcamp tradisional membutuhkan banyak waktu dan biaya untuk dijalankan, serta tidak benar-benar dioptimalkan untuk developer terbaik. Anda membantu orang yang sebenarnya sejak awal tidak terlalu membutuhkan bootcamp dan hanya memerlukan titik awal bagi kariernya, atau terus mendampingi orang yang mungkin tidak akan berhasil tanpa dukungan berkelanjutan tersebut. Kedua jalur itu tidak benar-benar dapat menskalakan onboarding developer sesuai kebutuhan Solana saat ini.

Jadi, pertanyaan yang lebih baik adalah: bagaimana Anda dapat memberi kesempatan kepada mereka yang benar-benar mampu di antara 800 hingga 900 orang yang ditolak bootcamp? 

Untuk Blueshift, jawabannya adalah membangun pembelajaran mandiri berkualitas tinggi. Jika dapat mengikuti materinya, Anda dapat menyelesaikannya sesuai waktu Anda sendiri dan memperoleh NFT sebagai bukti. Semuanya open source, dan kami secara aktif mendorong pull request dari komunitas serta menyoroti orang-orang di Twitter untuk membantu mempromosikan dan merintis karier mereka. Orang-orang mengirimkan perbaikan, kami menggabungkannya, dan seluruh platform pun menjadi lebih baik.

Alih-alih berkata, “Maaf, Anda tidak diterima. Semoga beruntung lain kali,” kami berkata, “Ini kurikulumnya, selesaikan dengan luar biasa sesuai waktu Anda sendiri.” Pelajaran kami sudah diterjemahkan ke dalam delapan bahasa, sehingga orang-orang dapat mengadakan meetup atau bootcamp di mana pun di seluruh dunia. Superteam dapat menggunakannya. Forma dapat menggunakannya. Pada akhirnya, Anda memiliki standar yang objektif: orang-orang memperoleh NFT yang sama, Anda mengetahui level mereka, lalu dapat merekrut atau memberi mereka tantangan yang sesuai.

Blueshift menyelesaikan semua masalah ini dengan berfokus pada developer yang termotivasi dan mampu mengikuti pembelajaran mandiri berkualitas tinggi. Kami menerima kenyataan bahwa jika semuanya dijadikan open source, orang-orang akan semakin kritis, sehingga kebijaksanaan komunitas akan terlihat. Karena itu, kami menggabungkan PR mereka dan akhirnya memiliki platform serta konten edukasi terbaik yang tersedia.

Pada dasarnya Anda telah menjawabnya secara tersirat, tetapi untuk membuatnya lebih gamblang: apakah Anda memandang edukasi developer lebih sebagai masalah penerjemahan—membuat ide kompleks lebih mudah diakses—atau lebih sebagai masalah bootcamp—membawa banyak orang mencapai level dasar dengan cepat, atau justru hal lain sepenuhnya?

Ya, masalah utama edukasi developer saat ini adalah resource gratis yang kami sediakan sangat buruk. Banyak di antaranya sudah usang. Pada dasarnya, semua orang menulis dengan Anchor atau Pinocchio. Tidak ada yang menggunakan solana_program. Semuanya menjadi usang dengan sangat cepat. Jadi, dengan membuat semuanya open source, kami dapat menyusun konten berkualitas secara cepat dan cermat, lalu memeliharanya. Tampaknya tidak ada orang lain yang benar-benar ingin melakukan ini. Jadi, kami akan melakukannya karena tidak ada orang lain yang bersedia. 

Bahkan Mert menyadari hal ini enam bulan lalu ketika kami membicarakannya. Dari sudut pandangnya, ia senang ada orang yang memutuskan untuk peduli terhadap masalah ini. Dan siapa yang lebih tepat daripada kami, bukan? Saya beruntung menjadi salah satu developer yang lebih berpengaruh di bidang ini. Semuanya open source. Kami tidak memiliki moat, haha. Kami tidak menerima hibah besar dari Solana Foundation—kami mendanainya sendiri. Kami melakukan semuanya sendiri, dan satu-satunya moat kami adalah eksekusi. 

Edukasi adalah sebuah spektrum. Anda perlu menemui orang-orang pada level mereka dengan materi yang cukup menantang agar mereka mempelajari sesuatu, tetapi juga cukup mudah dipahami dan didekati agar mereka terus kembali. Kemudian Anda mulai memancing minat teknis mereka untuk bergerak ke kanan. Menurut saya, saya cukup ahli melakukannya, sehingga Blueshift menjadi platform pemancing minat teknis terbaik. Lalu tiba-tiba Anda berkata, “Apa-apaan ini? Mengapa sekarang saya menulis assembly?” 

Discord Blueshift juga menyediakan layanan DevRel untuk membantu orang-orang membangun proyek ketika mereka menghadapi kebuntuan. Hal terpentingnya adalah sebagian besar pertanyaan di sana bahkan tidak saya jawab—komunitaslah yang menjawabnya. Dan hasilnya jauh lebih baik daripada StackOverflow atau platform lain karena Anda memiliki komunitas yang kuat dan aktif.

Seperti apa masa depan Blueshift?

Masa depan Blueshift pada dasarnya terdiri dari dua produk: Coursera dan LeetCode. Kami sudah memiliki versi yang lumayan—sebenarnya lebih dari lumayan, tetapi belum ideal—dari kedua produk tersebut, tetapi masih perlu ditingkatkan. Kami sedang mengerjakan V3, jadi semuanya akan menjadi jauh lebih baik. 

Kami ingin menjadi sangat efektif dalam melayani developer yang mampu mengikuti pembelajaran mandiri. Dan sejujurnya, developer seperti itulah yang lebih saya inginkan di ekosistem ini. 

Saya menginginkan orang-orang yang langsung menyingsingkan lengan dan mencoba. Kami ingin mempermudah mereka melakukan hal tersebut dengan menyediakan resource yang bagus. Jadi, jangan membuang waktu mereka dengan materi usang, dependency yang rusak, dan sebagainya. 

Tujuan akhirnya adalah memiliki platform tempat orang-orang dapat mempelajari apa yang mereka minati tanpa dikotak-kotakkan, lalu membuktikan kemampuan mereka dengan menyelesaikan berbagai tantangan. 

Pertanyaan Kilat

Musik apa yang baru-baru ini Anda dengarkan saat menulis assembly?

Haha, biasanya death metal.

Apa syscall terbaik untuk disalahgunakan di Solana?

secp256k1_recover

Apakah Anda lebih memilih menulis C# atau Java selama sisa hidup Anda?

Tidak.

Mana yang lebih baik: model berbasis UTXO atau account?

Satu UTXO nilainya lebih tinggi.

Jika memiliki resource tanpa batas, apa inisiatif edukasi impian yang akan Anda luncurkan besok?

Blueshift plus IRL. 

Apa satu kiat untuk mengajarkan konsep Solana tingkat rendah kepada developer baru tanpa membuat mereka takut?

Humor yang menertawakan diri sendiri.


Kesimpulan

Di dunia abstraksi tingkat tinggi dan penerimaannya sebagai “realitas” demi menarik massa, Dean Little berdiri sebagai jembatan langka—seorang alkemis tingkat rendah yang menempa alat menggunakan unsur paling mendasar untuk mengangkat orang lain ke atas bahunya. Perjalanannya dari roket hingga menyebarluaskan update oracle yang sangat dioptimalkan mengungkap etos seorang builder. Etos yang tak tergoyahkan dalam mengejar kebenaran: rancang untuk menghadapi kegagalan, berinovasilah melawan batasan, dan jangan pernah memercayai apa pun secara membabi buta.

Baik saat memaksa vault kuantum menjadi nyata maupun menskalakan Blueshift untuk memancing minat teknis generasi berikutnya dari developer Solana yang luar biasa (semoga mereka dapat berdiri di atas bahu para raksasa dan tidak perlu bersusah payah seperti kami semua), Dean mewujudkan api seorang puris yang ditempa oleh kehangatan komunitas. Ini menjadi pengingat bahwa kemajuan sejati bukan hanya soal melempar lebih banyak kayu ke dalam api atau menumpuk lapisan demi lapisan—melainkan mengupas kembali lapisan-lapisan tersebut untuk mengungkap dengungan mesin, lalu mengajari orang lain menari bersamanya.

Saat Solana melaju menuju lompatan berikutnya, entah itu paritas penuh EVM, Alpenglow, atau 100.000 update oracle per detik, karya Dean membisikkan tantangan bagi kita semua: Mengapa puas dengan kebohongan yang halus jika Anda dapat menyolder realitas Anda sendiri? Jika rasa ingin tahu adalah percikannya, orang-orang seperti Dean adalah bahan bakarnya.

Terjunlah, salahgunakan syscall, jejalkan fungsionalitas kompleks ke dalam sebuah transaksi, dan siapa tahu—mungkin Anda akan muncul membawa sekoci kuantum Anda sendiri.

Berlangganan Helius

Ikuti perkembangan terbaru dalam pengembangan Solana dan dapatkan pembaruan saat kami memublikasikan postingan