Crypto Bounty Hunter-1

监控录像显示，周三下午三点，一个人进了小区大门。但监控录像只是显示，它不判断这个人是不是小偷。判断在保安那儿，在物业那儿，在警察那儿。加密世界也一样——数据是数据，判断是判断，但很多人把这两个搞混了。

@BabylonLabs_io 白皮书里反复出现一个词："price oracle"，价格预言机。第4节的对比表格里，第一行就是"所有方案都依赖一个可信的价格预言机——这是抵押借贷无法回避的需求"。白皮书用了两个词来描述它——"trusted"和"unavoidable"，可信的，无法回避的。然后它就跳到下一段了，像路过一个不想多待的房间。

预言机的问题不是它可能被攻击——这个大家讨论得够多了。预言机的真正问题在于它把"客观事实"和"人类判断"焊死在了一起。BTC价格跌到50000美元以下就清算——这看起来是个客观的、可验证的、机械执行的条件。但"BTC价格"这四个字本身就是一整套价值判断的压缩包：哪个交易所的价格？成交量加权还是时间加权？期权市场隐含波动率要不要纳入？闪电崩盘算不算？预言机给的不是客观事实，是一个被某个特定方法论加工过的数据产品。

金库的预签名交易会在"价格条件满足"时触发清算，但它不区分这个价格是来自20个交易所的加权均价，还是来自一个流动性枯竭的小交易所的瞬时报价。第5节提到清算人"监控价格喂价和金库状态"——这个"监控"动作本身就隐含了判断。清算人不是机器，他会选择信哪个数据源、在哪个时刻行动。一个被设计成"机械执行"的系统，最后一步的执行者还是人。#baby

$BABY 的治理角色，真正要定义的不是技术参数，而是这个"事实与判断的边界"。预言机选型、异常价格的处理规则、清算触发后的人工复核窗口——这些都是治理要啃的硬骨头。代码执行清算，但代码不知道什么叫"合理价格"。DYOR。

你有没有试过跟人合伙买东西？比如合租一台游戏机，说好一人用三天。头一周还挺和谐，第二周开始有人拖时间，到第三个月机子到底在谁家都搞不清了。共有资产最大的敌人，往往不是恶意，是日常协作的磨损。

@BabylonLabs_io 白皮书里面有一句话安静地趴在那儿，几乎没人会读第二遍：“每个金库对应一个 UTXO。”技术含义很直白——你的比特币没进大池子，而是锁在一个能在比特币账本上被明确指认的交易输出里。可经济含义要深得多：这个金库是你跟对手方的共有资产，但它的“所有权证明”在链上是非此即彼的——要么还没花，要么花掉了。中间那些复杂的共有关系，链上看不见。

这就生出一个麻烦。Bob 跟 Larry 在金库运行期间闹了别扭——不是那种需要启动挑战机制的恶意纠纷，而是民事级别的小摩擦：Bob 想提前还款，Larry 不干；Larry 想把债权转给第三方，Bob 不认那个受让人。这些不涉及欺诈，预签名交易里没给它们留分支路径，比特币链上也没有调解机制。两个人只能私下商量。商量不成呢？金库就变成一座打不开的牢笼。#baby

$BABY 在白皮书描述的治理里，长远看可以在这儿搭一层软性协调层——引入标准化仲裁模板、建债权转让白名单、或者给金库设一段协商冷静期。可这些不是密码学能啃的骨头，是制度建设。UTXO 给了金库原子级的干净利落，却也一刀剥掉了共有资产必需的灰度空间。

一个挺有意思的悖论：金库的安全感恰恰来自它没有模糊地带，可它要伺候的金融活动——借贷、抵押、清算——从头到脚塞满了需要人肉判断的模糊地带。BABY，大概就是持币者在清晰与模糊之间咬牙划下的那条线。DYOR。

你有没有丢过一次性打火机？不是被偷，是用完随手搁哪儿了。它打从出厂那天就注定了只够点几十次烟，然后变成一块塑料垃圾。加密世界里也有这种“一次性”的东西，只不过它是被刻意设计成这样的。
@BabylonLabs_io 在讲挑战流程时，捎带了一个看着纯技术味儿的细节：被挑战方得提交“Lamport 签名”来应诉。Lamport 签名是密码学里最老的后量子签名方案之一，可它有个挺特别的脾气——一个密钥对，只能用一次。签过一回名，密钥就废了，再用安全性直接归零。白皮书拿它当挑战验证的工具，却在不经意间给金库系统塞进了一个隐形的计数器。

这意味着什么？意味着 Bob 或 Larry 每被挑战一次、每被迫应诉一次，都在烧掉一组只能用一回的密钥材料。这些密钥不是临时变出来的，是金库创建时就提前算好、存好的。要是一个人掺和了好几个金库，或者同一个金库被人翻来覆去地挑战，他的密钥库存就会慢慢见底。耗尽了怎么办？白皮书没给答案。是金库冻住？是强制关门？还是自动切到备用方案？这是一笔被悄悄跳过去的技术债。

$BABY 的治理职能，倒可以在这儿使上劲。每个金库预设多少组 Lamport 密钥、耗干了兜底策略是什么、紧急状态下能不能通过治理投票强制解锁——这些全是治理层迟早得回答的问题。可麻烦在于，Lamport 签名的消耗速度全看恶意挑战有多疯，而恶意挑战的频率根本没法预测。一个被盯上往死里围攻的金库，可能几个钟头就把所有密钥储备烧个精光。#baby

去信任系统的脆弱性，有时候不藏在大动脉里，而是躲在资源管理的边角料里。Lamport 签名就是这种边角料——小到平时没人提，可真用完了，就是天大的事。DYOR。

加密圈对“池”这个字有种莫名的迷恋——流动性池、借贷池、抵押池。听得久了，你很容易生出一种错觉，以为钱往池子里一倒，就自动融成了一种均匀的、随处可舀的液体。可比特币金库压根不是池子，是保险柜。一池水跟一排保险柜，是两样完全不同的东西。

@BabylonLabs_io 白皮书讲借贷金库设计时，埋了一句特别容易被扫过去的话：“金库创建需要 k-of-n 个清算人共同签名。”乍看就是个技术参数，但它其实悄悄定义了整套系统的物理形态——不是一大口池子，而是 n 个独立保险柜，每个柜子上挂 n 把锁，凑够任意 k 把就能开。这就不由得让人多想一步：不同保险柜上的那排锁，是同一批人吗？

要是同一批清算人管着所有金库，那这系统骨子里还是池子——清算风险被集中到了同几个人身上。可如果每个金库都由不同的清算人组合来管，这帮人彼此之间怎么协调？白皮书里补了一句“大额出资人也能参与签名”，却没回答一个更扎手的操作问题：当某个金库触发清算条件，那 k 个攥着钥匙的人里头，到底谁去执行？是头一个抢到机会的人独吞，还是按比例分配？要是前者，清算人之间就成了抢跑游戏，慢的永远喝不到汤，慢慢就没人干了。要是后者，就得有一套分配规则——谁写？怎么强制？#baby

$BABY 的治理功能，真正要解的就是这类协调死结。清算人怎么注册、怎么轮换、收益怎么分、抢跑怎么防，这些全不在金库的预签名交易里，全在治理参数里蜷着。金库只管锁的结构长什么样，可谁管钥匙、管钥匙的人之间怎么排班干活，这些问题被白皮书用“k-of-n”四个字符一把打包压缩了。

去中心化从来不是把一个大锁敲碎成一堆小锁就完事了。真正的坎，是锁和钥匙之间怎么配。DYOR。

你有没有盯着自动售货机的出货口干等过？投币，按键，听见里头哐当一声闷响——然后，卡住了。货没掉下来，钱已经扣了。你拍机器、找客服、填工单，折腾半天不是心疼那几块钱，是不服气。流程跑了一半卡在中间状态，比根本没跑更让人窝火。

@BabylonLabs_io 白皮书把金库的快乐路径画得清清爽爽：存款、铸币、提款、销毁，首尾衔接，跟地铁线路图似的。可它没展开一个所有跨链系统都绕不开的幽灵——跨步确认失败。讲借款人把金库 UTXO 信息发给合约链，轻客户端验证通过后铸出 collBTC，描述是一步到位的、顺序的。但现实中这是两张异步网络的握手：比特币出块平均十分钟，合约链可能几秒一个块。信息到达的时间差里，金库的状态在两条链上是割裂的。

铸币交易甩出去了，比特币那边偏偏在这当口触发了一笔意外花费呢？轻客户端因为短暂分叉，同步到了一个错的区块头呢？这些不是攻击，是网络层面的正常喘气。可金库的预签名逻辑假设世界是铁板一块的——你锁了就是锁了，铸了就是铸了。中间那层灰蒙蒙的、悬而未决的、需要人肉判断的状态，全被白皮书压进了箭头与箭头之间的空白地带。#baby

$BABY 待在这里的位置，不是技术性的，是治理性的。当中间状态真的砸下来、系统没给你预备任何自动化处理路径的时候，谁来拍板仲裁？白皮书里的治理框架，说穿了就是给这些代码罩不住的例外留一道后门。可问题在于，治理响应是按天甚至按周算的，而链上状态的漂移是按秒跑的。等你这头投完票，那头黄花菜都凉透了。

这不是 Babylon 一家要面对的困局。所有想在异步网络上搭出同步逻辑的系统，都得跟这个幽灵同床共枕。白皮书不写它，不是因为它不存在，是因为它根本写不进白皮书里。DYOR。

赌场有条不成文的规矩：你要是连着赢太多把，赌场有权请你走人。不是抓到你出老千，是你把赔率模型给捅破了。这让我想起@BabylonLabs_io 白皮书里一个极其微妙的设计——“挑战失败，取消未来提款资格”。

Babylon白皮书解释 BitVM3 挑战流程时，话说得挺明白：Larry 要是发起一次恶意挑战，混淆电路让人拆穿，秘密被 Bob 一把提走——那他可不光是赔掉押金，还“丧失了挑战未来提款的权利”。这句话夹在一堆技术描述里，毫不显眼，可它才是整个博弈系统那堵隐形的承重墙。

这个设计真正要防的，其实藏得很深：不是直来直去的恶意，而是“试探性恶意”。你琢磨一下，要是一个清算人可以翻来覆去地发起挑战，输了就赔点钱，赔完接着下场玩儿，他就有动机拿高频挑战当探针，一轮一轮地刺探系统的边界。每次都赌对方不敢应战，或者赌自己能撞上一处证明漏洞。把挑战失败硬生生拖成一场消耗战。但“取消未来资格”这个惩罚，咔嚓一下把这循环给剪断了——你只能输一回，输了就出局。挑战不是无限续杯，是单程票。

可这么一设计，新的麻烦也跟着冒出来了：要是善意误判呢？挑战者因为预言机延迟、数据同步偏差，或者干脆就是自己摁错了计算器，发起了一次诚诚恳恳却技术上砸了锅的挑战——他也得永久出局？白皮书对“恶意”和“误判”不作区分，执行层只管看结果。这等于是把法官酌情裁量的灰色地带，一巴掌拍扁成一个冷冰冰的二进制开关。#baby

$BABY 蹲在白皮书里的位置，恰好能伸手填上这个坑。治理可以拍板“取消资格”到底挂多久、有没有申诉通道、误判的人怎么慢慢爬回来。代码只负责铁面无私地执行惩罚，而治理负责定义“什么才叫恶意”。换句话说，BABY 就是持币者给这套系统死死攥住的最后那一丝人情味裁量权。DYOR。

Di persidangan ada semacam peran yang disebut “saksi ahli”—dia tidak berdiri di pihak penggugat maupun tergugat, namun begitu ia mulai bicara, neraca putusan ikut bergoyang. Di dunia terenkripsi pun ada sosok seperti itu yang juga “bersembunyi” di sana, hanya saja kebanyakan orang tak pernah benar-benar menatapnya. Dokumen whitepaper bolak-balik membahasnya, tetapi selalu hanya membungkusnya dengan lapisan istilah teknis, tanpa pernah membentangkan logika kekuatannya di dalam.

@BabylonLabs_io Di bagian 5 whitepaper dibahas soal pinjam-meminjam, bagian 6 membahas stablecoin, bagian 7 membahas kontrak perpetual—tiga skenario yang tidak ada hubungannya sama sekali, justru dipaksa memakai satu kalimat yang sama: “Diperlukan sebuah oracle harga yang tepercaya.” Coba cermati kata sifatnya—“tepercaya”. Seluruh arsitektur brankas (vault) mati-matian bergulat meminimalkan kepercayaan: Bob tidak perlu percaya pada Larry, Larry juga tidak perlu percaya pada Bob; likuidator ditekan habis-habisan oleh struktur permainan, sementara penantang dikunci ketat oleh jaminan ekonomi. Hanya oracle, whitepaper mengaku satu kalimat: “tidak bisa dihindari”, lalu membiarkan semuanya berhenti di situ.

Tugas oracle sederhana sampai tak bisa dibuat lebih sederhana: memberi tahu brankas berapa nilai BTC saat ini. Begitu harga menembus garis likuidasi, likuidasi pun terpicu; saat harga merangkak pelan kembali, semuanya berjalan seperti biasa. Namun gerakan “memberi tahu” itulah satu-satunya titik kekuasaan dalam sistem yang tidak bisa dihilangkan oleh bukti pengetahuan nol (zero-knowledge) dan sirkuit pengaburan. Oracle memberi harga apa, brankas akan mengeksekusi hasil apa pun sesuai ketentuan. Oracle tidak perlu mencuri kunci privatmu; yang dibutuhkannya hanya pada satu momen yang menentukan, memberikan satu harga yang menentukan—kelebihan seratus dolar atau kekurangan seratus dolar saja sudah cukup untuk menentukan apakah bitcoinmu akan tergeletak aman dan tenteram, atau dipotong habis oleh palu likuidasi.

#baby

$BABY Posisinya di dalam lubang hitam kekuasaan ini, pada bagian 10 sebenarnya disinggung, tetapi tidak dibuka: tata kelola (governance). Oracle dipilih yang mana? Kandidat penggantinya siapa? Seberapa panjang keterlambatan pengumpanan harga boleh sebelum dianggap abnormal? Kalau abnormal, apakah likuidasi dihentikan atau dialihkan ke sumber data cadangan? Semua itu tidak ditulis kaku di kode brankas, melainkan dimasukkan ke dalam parameter tata kelola. Orang yang memegang BABY, sedang memasang pagar bambu itu—mengelilingi “satu-satunya celah kepercayaan” itu—selapis demi selapis.

Sebuah batas langit-langit keamanan untuk sistem tanpa kepercayaan, pada akhirnya bersandar pada komponen yang paling tidak ingin ia percaya: oracle. Oracle, itulah komponennya. Brankas disusun setindah apapun, pada akhirnya juga tetap bekerja untuk oracle. DYOR.

Uang jaminan sewa ini: saat menyerahkannya gampang, saat mengembalikannya jadi menyebalkan. Tuan tanah selalu bisa menemukan alasan untuk memotong sedikit untukmu: cat dinding mengelupas, keran agak longgar, atau mesin penghisap asap belum dibersihkan bersih. Uang jaminan itu ada di tangannya, sehingga otoritas untuk menjelaskan ada di mulutnya. Ini membuatku tiba-tiba teringat satu detail yang tampak remeh tapi menggelitik pikiran di Bagian 3 whitepaper: “bond” di brankas—yakni jaminan yang dikunci lebih dulu untuk mencegah kecurangan—pihak proyek hanya meninggalkan satu kalimat, “Setelah brankas ditutup, jaminan akan dikembalikan.”

“Akan dikembalikan.” Siapa yang mengembalikan? Bagaimana cara mengembalikannya? Dikembalikan berapa? Tiga pertanyaan ini tidak dijabarkan lebih lanjut dalam whitepaper, tapi justru tiga hal itu menyinggung saraf paling rapuh dari sistem brankas.

Kembali ke mekanisme desain di Bagian 3 whitepaper @BabylonLabs_io : Bob dan Larry masing-masing menyetorkan sejumlah uang di rantai sebagai denda jika tantangan gagal. Maksud awalnya sangat jelas—untuk mencegah tantangan yang berniat buruk; kalau kamu asal bikin masalah, kalau kalah ya bayar. Namun bagaimana dengan skenario sebaliknya? Jika kedua pihak berperilaku dan memenuhi kewajiban dengan benar, ketika brankas habis masa waktunya dan ditutup secara normal, bagaimana jaminan itu dikembalikan kembali ke jalur semula? Apakah otomatis “dipulangkan”, atau perlu tanda tangan bersama lagi oleh kedua pihak? Jika yang kedua, maka pengembalian jaminan berubah menjadi babak permainan yang baru: salah satu pihak bisa dengan sengaja menahan tanda tangan, memeras pihak lain lewat biaya waktu agar mau mengalah. Jaminan awalnya dibuat untuk menghapus permainan, tapi pengembalian jaminan malah melahirkan permainan baru.

$BABY yang berjongkok di posisi celah ini, letaknya sangat halus. Bagian 10 memposisikannya sebagai token tata kelola, dan “aturan pengembalian jaminan” justru merupakan topik tata kelola yang paling klasik: bagaimana menetapkan nominal jaminan? Berapa lama batas waktu pengembaliannya? Kalau salah satu pihak tidak kooperatif dalam menandatangani, apakah ada mekanisme pelepasan paksa? Begitu parameter-parameter ini dikunci ke dalam kode, jadilah hukum yang tak bisa diganggu gugat. Tapi sebelum dikunci, parameter itu diputuskan lewat suara pemegang token. BABY tidak bisa mengendalikan permainan kecil antara Bob dan Larry, namun ia mengurung batas aturan permainan.

#baby

Hal yang paling ditakuti dari sistem tanpa kepercayaan adalah bukan orang jahat yang melakukan kejahatan secara terang-terangan, melainkan orang baik yang pelan-pelan dipaksa jadi jahat karena celah-celah aturan. Tindakan pengembalian jaminan itu sendiri tepat menjadi celah tersebut. DYOR.

Saat meluncurkan roket, yang paling menghabiskan bahan bakar sebenarnya bukan saat melayang di luar angkasa—melainkan puluhan detik ketika roket dipaksa menanjak dari permukaan bumi. Gravitasi paling berat di fase itu, setiap gram beban harus ditukar dengan beberapa ton daya dorong. Ini mengingatkan saya pada sebuah sudut yang jarang dibahas dalam buku putih: masalah cold start pada sistem yang meminimalkan kepercayaan.

@BabylonLabs_io Buku putih Bagian 1 mengakui dengan jujur: jembatan Bitcoin yang ada membutuhkan “komite penandatangan, sekelompok operator, dan sekelompok penantang”—ketiga pihak saling mengendalikan agar jembatan bisa berjalan. Logika brankas yang meminimalkan kepercayaan justru lebih keras: langsung memangkas dua pihak pertama, hanya menyisakan penantang. Masalahnya macet di sini: ketika sistem dimulai dari nol, siapa yang duluan melangkahkan kaki?

Bagian 3 justru menjawabnya dengan sangat transparan. BitVM3 mengharuskan Bob dan Larry masing-masing menghasilkan untuk satu sama lain sebuah sirkuit yang mengaburkan berukuran 43GB—tetapi prasyaratnya adalah kedua belah pihak sudah saling percaya bahwa pihak lain akan bekerja sama dengan baik menyelesaikan penyiapan. Anda harus lebih dulu bertukar kunci dengan pihak lawan, saling memverifikasi apakah sirkuitnya benar, dan menandatangani transaksi yang akan dipra-tandatangani bersama. Langkah-langkah ini tidak bisa ditempuh, jadi brankasnya pun tidak mungkin dibangun. Intinya, menjalankan rangkaian sistem “tanpa perlu percaya siapa pun” justru butuh semacam ritual “berbasis kepercayaan yang padat” dalam waktu singkat. #baby

Paradoks itu sendiri bukanlah celah, namun secara gamblang menciptakan problem ekonomi: siapa yang menanggung biaya inisiasi? Operator harus “membakar” waktu CPU untuk menghasilkan sirkuit, sedangkan pihak pembersih harus mengunci jaminan (deposit) untuk ikut dalam pra-tandatangan. Hal-hal itu, ketika ekosistem belum berjalan, sama sekali tidak menghasilkan keuntungan uang sepeser pun. Program insentif di Buku putih Bagian 10 yang bernomor $BABY , pada intinya, adalah menyuntikkan “kecepatan lepas” ke fase cold start. Subsidi token memaksa kesenjangan kekosongan kepercayaan dari nol sampai satu agar terisi—ketika sistem belum punya pendapatan, token adalah mesin penggerak gravitasi; setelah sistem bisa “menciptakan darahnya sendiri”, mekanisme pembakaran beralih dari mesin menjadi pompa hisap.

Sebuah sistem yang mengaku “tanpa kepercayaan”, justru saat lahir harus mengandalkan insentif awal untuk mendorong sekelompok orang menanggung sementara biaya kepercayaan itu. Kontradiksi ini tidak aneh; malah jujur. Semua jaringan terdesentralisasi tumbuh dengan terbata-bata seperti ini, hanya saja sangat sedikit orang yang mau menuliskannya secara terang-terangan dalam buku putih. DYOR.

Di dunia kripto ada sebuah istilah yang setiap kali saya dengar terasa canggung—“jembatan”. Jembatan itu menghubungkan dua sisi: kamu berjalan menyeberang, orangnya tetap ada, barangnya juga tidak hilang. Tapi yang dilakukan jembatan lintas-chain Bitcoin adalah: mengunci BTC-mu di satu tempat, lalu di sisi lain memberi kamu sebuah surat utang. Ini bukan jembatan, ini gadai.

@BabylonLabs_io Data pada Bagian 1 whitepaper juga menguatkan rasa tidak nyaman itu: WBTC dan cbBTC digabungkan, hanya menyentuh sebagian kecil dari total kapitalisasi pasar Bitcoin—kurang dari 1%. Apakah pemegangnya tidak ingin mendapatkan imbal hasil? Bukan. Semua orang secara bawah sadar paham: begitu kamu menyeberang, BTC-mu tidak lagi menjadi Bitcoin; BTC-mu berubah menjadi sebuah kewajiban di neraca lembaga kustodian tertentu.

Whitepaper Babylon Bagian 5 memberi pendekatan yang berlawanan: jangan memindahkan Bitcoin bolak-balik; biarkan protokol DeFi “melihat” Bitcoin itu dari jauh saja. Kamu mengunci BTC di brankasmu sendiri, lalu light client pada chain kontrak memverifikasi bahwa setoran itu memang ada, kemudian mencetak collBTC—sebuah simbol pencatatan yang hanya beredar di internal. Bitcoin asli berbaris rapi dan aman dari awal sampai akhir di blockchain Bitcoin, bahkan UTXO pun tidak dipindahkan. Yang ikut berpartisipasi dalam DeFi bukan asetmu, melainkan bukti kepemilikan atas asetmu.

Namun, di bawahnya tersembunyi sebuah paradoks. collBTC di chain kontrak adalah token standar ERC20 yang bisa dipinjamkan, bisa dikenai likuidasi, dan bisa digabungkan ke berbagai protokol ala Lego untuk dipakai dengan cara-cara yang beragam. Tapi “wujudnya”—brankas UTXO itu—sepenuhnya tidak bisa dipisahkan dan tidak bisa dikomposisikan. Di satu sisi ada likuiditas yang sangat bisa diprogram, di sisi lain ada sifat atom yang keras kepala. Peran $BABY di Bagian 10 justru adalah pelumas di antara dua logika itu: operasi brankas menghasilkan biaya, biaya itu dilelang untuk dibakar menjadi BABY. Secara esensial, ini membayar untuk setiap “kerugian translasi”—mengubah aset atom menjadi aset yang bisa diprogram: setiap kali kamu menerjemahkannya, kamu harus menghabiskan sedikit token untuk menjaga keseimbangan ekonomi.#baby

Menukar kewajiban dengan likuiditas, atau menukar bukti dengan likuiditas—dua filosofi keuangan yang benar-benar berbeda. Babylon memilih jalan yang kedua. Tapi bukti itu sendiri juga punya biaya pemeliharaan: data tantangan 43GB dan biaya potensial sekitar 93 dolar adalah buku besar fisik tempat filosofi itu benar-benar berjalan. DYOR.

Beberapa waktu lalu, unit kantin melakukan reformasi: dari “makan bergaya prasmanan” menjadi loket hidangan porsi kecil. Rekan kerja mengeluh, dulu mengambil satu porsi daging babi saus merah (hongshao rou) itu satu harga, sekarang harus terus mengawasi bibi itu sendok demi sendok berapa banyak—capek sekali. Tiba-tiba aku sadar: standardisasi jadi populer karena membuat semuanya lebih mudah—meski harus mengorbankan sedikit rasa adil, efisiensinya tinggi.

Gagasan itu membuatku meninjau lagi satu detail desain dalam Whitepaper @BabylonLabs_io yang dilewatkan kebanyakan orang. Bagian 2 membahas saat pembuatan brankas: ada satu kalimat yang terlihat teknis, “Setiap brankas berkorespondensi dengan satu UTXO.” Jika diterjemahkan, maksudnya: bitcoinmu tidak dicampur dengan milik orang lain ke dalam satu “kolam besar”, melainkan dikunci sendirian dalam “kamar kecil” yang bisa kamu tunjuk secara jelas.

Hal yang tidak intuitif di sini adalah bahwa selama bertahun-tahun DeFi terus mengejar apa yang disebut “liquidity pool”—mencampurkan aset semua orang, lalu mengandalkan kedalaman pool untuk menurunkan slippage dan meningkatkan efisiensi. Tapi Babylon justru berlawanan: di level Bitcoin, ia mempertahankan model UTXO, sehingga setiap jaminan adalah entitas yang disegel secara independen. Di bagian 5 whitepaper disebutkan bahwa brankas-brankas independen itu di sisi Ethereum akan “dicetak menjadi token ERC20 collBTC”—langkah ini pada dasarnya adalah proses penerjemahan: memaksa aset asli yang tidak standar untuk dimasukkan secara paksa ke dalam “cetakan” DeFi yang distandardisasi.#baby

Dari sini muncul ketegangan yang unik: di sisi Bitcoin, asetmu adalah yang tidak dapat dipertukarkan “brankas ini”; di sisi Ethereum, ia berubah menjadi “token itu” yang dapat dipertukarkan.$BABY Lantas, peran apa yang dimainkan di antara dua sistem bahasa mata uang tersebut? Kembali ke bagian 10: penagihan fee protokol dan pembakaran hasil lelang pada dasarnya adalah penetapan harga untuk layanan “penerjemahan” semacam itu. Setiap kali kamu melakukan satu kali penerjemahan, muncul satu kali biaya gesekan (friction cost); biaya itu kemudian berubah menjadi tekanan deflasi BABY.

Jujur saja, keanggunan sekaligus kerapuhan dari desain pembukuan ganda yang berjalan paralel adalah dua sisi dari satu koin yang sama. Keanggunan karena desain ini menghormati filosofi Bitcoin; kerapuhan karena lapisan penerjemahan itu sendiri menambah satu permukaan serangan. Menara Babilonia dua bahasa mata uang itu—dibangun menjadi mukjizat; jika tidak, itu menjadi hal yang biasa. DYOR.

Pernahkah kamu memikirkan hal seperti ini: kapitalisasi pasar Bitcoin sekarang sudah sedemikian besarnya, sampai-sampai dengan mantap menempati peringkat lima besar dunia—namun sebagian besar waktu nilainya hanya diam saja, tidak menghasilkan bunga, dan tidak terlalu likuid. Intinya, ini sama sekali bukan masalah teknis, melainkan masalah kemanusiaan.

@BabylonLabs_io di bagian 1 whitepaper ada data set yang membuatku menatap layar cukup lama—saat ini, Bitcoin yang dijembatani ke platform smart contract, jumlahnya bahkan tidak sampai 1% dari total. WBTC ditambah cbBTC, dua aset jembatan terbesar, jumlah totalnya cuma segitu. Kenapa bisa begitu? Bukan karena para pemegangnya tidak mau menebar dana ke DeFi untuk cari imbal hasil—melainkan karena mereka benar-benar tidak berani. Jembatan yang ada sekarang, atau modelnya “satu orang memegang kendali” secara tersentralisasi, atau perlu sekelompok orang saling mengawasi agar bisa berjalan. Bukankah itu sama saja menjual pergi jiwa Bitcoin—self-custody yang terdesentralisasi?

Aku merasa, whitepaper Babylon ini sebenarnya mencoba menembus satu lapisan yang lebih dalam: apakah ada cara yang bisa menjaga tetap kuat “sifat tak tersentuh” Bitcoin, sekaligus membuatnya mengalir ke dunia DeFi yang lebih likuid dan leluasa beraksi? Jawaban yang mereka berikan adalah brankas trust-minimized—Bitcoin sama sekali tidak perlu keluar dari chain aslinya, tapi tetap bisa ikut berpartisipasi dalam aktivitas keuangan di chain lain.

Kalau logika ini benar-benar bisa dijalankan sampai tuntas, posisi token $BABY jelas punya daya tarik besar. Token itu bukan sekadar “governance token” palsu yang hampa, melainkan titik penangkapan nilai yang benar-benar mengunci sistem. Bagian 10 sangat terus terang: biaya protokol akan diubah menjadi BABY melalui lelang otomatis, lalu langsung dibakar. Coba kamu renungkan desain ini: semakin banyak orang mengunci Bitcoin ke DeFi, BABY akan semakin diperas, semakin langka—dan yang paling enak adalah—dari awal sampai akhir, tidak perlu siapa pun mengutak-atik secara manual.#baby

Kalau jujur, gagasan “membuat aset menjadi mesin penggerak” punya keindahan yang sederhana di intinya. Tapi keindahan saja tidak cukup—masih ada beberapa gunung besar yang harus dilewati untuk bisa diterapkan. Rintangan teknis, edukasi pasar, audit keamanan—di setiap langkah, bisa saja terjadi kegagalan total. Arah besarnya tidak salah; kita tetap harus melangkah sedikit demi sedikit. DYOR.

Beberapa hari lalu aku merapikan lemari, dan tanpa sengaja menemukan jaket lama. Saat meraba bagian lapisannya, ada kantong rahasia yang dijahit di dalam. Begitu tangan masuk, keluarlah uang 200 yuan. Kejutan tak terduga seperti “satu barang diam-diam melakukan dua hal sekaligus” membuatku teringat pada sebuah desain yang sangat mudah terlewat di Bab 8 whitepaper @BabylonLabs_io .

Sebelum ini, main line Babylon adalah staking Bitcoin—kamu mengunci BTC, membantu chain PoS melakukan verifikasi keamanan, lalu dapat imbal hasil staking. Sekarang mereka membuat DeFi vault: kamu mengunci BTC sebagai jaminan, lalu meminjam stablecoin atau melakukan trading. Secara permukaan ini terlihat seperti dua lini produk yang masing-masing jalan sendiri, benar? Tapi ada satu kalimat di Bab 8 yang membongkar kertas penutupnya: “Staker dan borrower dapat membuat sebuah single vault, sekaligus dengan tiga kondisi pengeluaran: redemption/un-staking, liquidation, dan slashing.”

Kalau diterjemahkan ke bahasa sehari-hari: dengan satu BTC yang sama, bisa sekaligus distaking di Babylon untuk mendapat imbal hasil, dan juga dipakai sebagai jaminan di dalam vault untuk meminjam likuiditas. Dulu saat kamu memegang 1 juta BTC, kamu hanya bisa memilih satu jalan; sekarang BTC itu bisa kerja dua kali dan menghasilkan dua kali lipat. #baby

Lalu, ini berarti apa bagi $BABY ? Coba kamu cermati—cukup “berisi” dan menarik. Kalau di masa depan banyak BTC yang sudah dipastikannya/staking juga masuk ke DeFi vault, maka biaya protokol yang dihasilkan vault tidak hanya berasal dari uang baru yang masuk, tapi juga “menggulirkan” dana staking yang sudah ada. Dan kalau kita kembali ke mekanisme di Bab 10—otomatis auction lalu dibakar—semakin banyak biaya, semakin besar jumlah yang dilelang menjadi BABY dan ikut terbakar. Dengan kata lain, dua jalur staking dan DeFi tidak saling mengalihkan, malah seperti saling menyuapi, membuat nilai terus bergulir semakin nyata.

Jujur saja, konsep “satu batu bata untuk dua tembok” di baliknya membutuhkan koordinasi teknis yang sangat matang. Whitepaper juga tidak menyembunyikannya: mereka menyebut dengan jelas bahwa ini harus dibangun dengan asumsi bahwa dua sistem—vault dan staking—sama-sama berjalan stabil. Ide memang cerdik, tapi ketika dua sistem yang sudah cukup kompleks untuk meminimalkan trust digabungkan, kemungkinan ada kesalahan juga mungkin hasil kali dari risikonya. Arah sudah benar, masih panjang perjalanannya. DYOR.

Beberapa waktu lalu, seorang teman meluapkan keluh kesahnya dengan gigi terkatup. Dia menyimpan dana di sebuah protokol pinjaman DeFi, dan saat terjadi likuidasi, dia menyaksikan asetnya diambil paksa dengan harga serendah yang benar-benar keterlaluan—bahkan tidak ada kesempatan untuk sekadar mengulurkan tangan menahan. Menurutnya: aturan ditetapkan oleh orang lain, eksekusinya juga dijalankan oleh pihak lain; Anda hanya bisa melongo, dan satu-satunya pilihan Anda adalah percaya.

Kejadian ini membuatku memikirkannya cukup lama. Kemudian, saat menelusuri whitepaper sebanyak @BabylonLabs_io , sebuah detail yang mungkin luput dari perhatian banyak orang tiba-tiba menjadi nyambung. Bab 5 membahas rancangan brankas pinjaman (lending vault), dan menyebut bahwa pembuatan brankas memerlukan “tanda tangan bersama k-of-n dari para likuidator”, bukan suara bulat, dan bukan pula keputusan satu orang. Jujur saja, kalau dilihat sekilas itu hanya semacam parameter teknis, bukan? Tapi setelah duduk dan merenungkannya, ternyata di baliknya tersimpan pemikiran strategi permainan yang cukup licik.

Bayangkan: kalau brankas hanya “dikunci” di tangan satu likuidator, maka peminjam pada dasarnya mempertaruhkan seluruh harta dan nyawanya pada nurani orang itu—dia bisa menunda, bisa berbuat jahat, bahkan bisa bersekongkol dengan peminjam untuk mengeruk pihak pemberi dana. Lalu, di mana ketajaman k-of-n sebagai kunci? Skema ini membuat para likuidator saling mengawasi: kalau Anda tidak bertindak, orang lain akan bergerak. Anda ingin berbuat curang? Di samping Anda ada banyak pasang mata yang menatap tajam. Pada intinya, ini memotong dengan satu tebasan tali rapuh “percaya pada satu orang baik”, lalu langsung menggantinya dengan struktur permainan (game theory)—jadi siapa pun tidak perlu saling percaya. #baby

Whitepaper $BABY di bagian yang sama juga menambahkan satu langkah lagi: bukan hanya likuidator, pihak pemberi dana dalam jumlah besar pun bisa ikut berpartisipasi dalam tanda tangan bersama dan proses penantangan untuk brankas. Trik ini terasa sangat masuk akal—siapa uangnya terkunci di dalam, dia otomatis akan menatap dengan mata seterang mungkin. Bukan karena mengandalkan aturan moral atau disiplin diri; semata-mata karena kepentingan yang “mengikat” di sana—kalau satu kena dampaknya, semuanya ikut terdampak.

Jujur saja, desain seperti Babylon justru membuatku merasa lebih tepat sasaran dibanding sekadar memamerkan otot teknis. Teknologi memang bisa diiterasi, tapi mampu membekukan kelemahan manusia ke dalam kode dan mengurungnya—bukankah ini wajah DeFi yang seharusnya? Tentu, soal k berapa dan n bagaimana ditentukan, jika ambang batas terlalu tinggi sistem bisa jadi kaku, kalau terlalu rendah kita khawatir tidak mampu menutup risiko; parameter-parameter itu harus disetel pada “takaran panas” yang pas, dan saat ini tak ada yang berani memastikan dengan jaminan. Rancangan boleh terdengar indah di kertas, tetapi kemampuan nyata adalah apa yang bisa dihasilkan dari data di rantai. DYOR.

Beberapa hari lalu, saya membedah satu insiden keamanan bersama teman yang berfokus pada risk control on-chain. Metode serangannya tidak terlalu canggih: sebuah protokol pinjaman-pinjaman melakukan upgrade parameter likuidasi tiga minggu lalu, tetapi cache di sisi front-end masih berbaring di versi lama. Pengguna menatap aturan lama di layar untuk mengambil keputusan, sementara peretas sudah lebih dulu mengendus celah pada aturan baru dan diam-diam melakukan arbitrase. Teman itu melemparkan satu kalimat yang membuat merinding: “Bukan karena lawan terlalu pintar, tapi karena aturan kita sendiri sudah kedaluwarsa.”

Kalimat itu menarik saya kembali ke dokumen putih @NewtonProtocol , memaksa saya menyoroti kembali satu detail yang sebelumnya benar-benar saya abaikan—di Bagian 6.5, beberapa baris tentang “atribut waktu” pada kredensial. Teks aslinya sangat tertahan: hanya mengatakan bahwa kredensial membawa metadata yang sudah kadaluwarsa, dan mendukung refresh inkremental, tanpa harus setiap kali membongkar dan memulai dari nol. Tapi semakin saya pikirkan, saya makin yakin bahwa yang diatur Newton di sini sebenarnya bukan kredensialnya sendiri, melainkan “kadaluwarsa”-nya.

Mengapa dua kata “kadaluwarsa” layak diangkat secara terpisah? Dunia on-chain sudah lama hidup dalam ilusi—selama kodenya tidak berubah, aturan seolah akan selalu keras. Namun kenyataannya, aturan kepatuhan di dunia nyata setiap hari diam-diam membalik halaman: daftar sanksi terus berubah, status KYC bisa berakhir masa berlakunya, skor kredit juga punya masa simpan. Jika Anda memakai penggaris dari tiga bulan lalu untuk mengukur transaksi hari ini, hasil ukur tersebut secara hukum bisa saja tidak bernilai apa-apa. Yang diselesaikan oleh mesin strategi Newton, secara permukaan adalah “apakah bisa menjalankan aturan”, tetapi di dalamnya itu adalah “apakah yang dijalankan adalah versi yang tepat untuk saat ini”. Strategi itu sendiri dikunci pada versi lewat content addressing IPFS; penyedia data mengambil daftar terbaru secara real-time; operator menegaskan versi strategi dan tinggi blok melalui tanda tangan BLS dari token yang dipertaruhkan, mengikat keduanya dalam satu paket. #Newt

$NEWT Token dalam mekanisme ini berperan sebagai “jaminan ekonomi yang bersifat tepat waktu”. Begitu hasil penilaian kedaluwarsa ditantang dan dibongkar, token yang dipertaruhkan tetap akan dikenai sanksi—tidak peduli. Ini seperti memaksa seluruh sistem dengan uang sungguhan, agar “waktu” menjadi variabel keamanan yang tidak boleh malas. Jika Anda terlambat satu detik sampai kedaluwarsa, biayanya adalah penguapan aset yang benar-benar nyata. Tidak ada lagi yang berani berpura-pura bahwa aturan lama masih bisa dipakai. DYOR.