Masalah Inti: Di Bawah Biner, Memverifikasi Kepercayaan

Saat kebanyakan orang mengunduh Bitcoin Core, interaksi mereka dengan sistem build hanya berlangsung dalam beberapa klik. Mereka mengambil executable binary dari perangkat lunak, memverifikasi sebuah tanda tangan (semoga!), dan mulai menjalankan node Bitcoin. Yang langsung mereka lihat adalah perangkat lunak yang sedang berjalan. Yang tidak mereka lihat adalah sistem build dan proses ekstensif yang menghasilkan perangkat lunak tersebut. Sebuah sistem build yang mewakili prinsip-prinsip Bitcoin tentang desentralisasi, transparansi, dan keterverifikasian.

Di balik unduhan itu terdapat kerja teknik selama bertahun-tahun yang dirancang untuk menjawab pertanyaan sederhana: “Mengapa siapa pun harus mempercayai perangkat lunak ini?” Jawabannya adalah: Anda tidak seharusnya harus mempercayainya. Anda harus bisa memverifikasinya.

Di era ketika serangan pada rantai pasokan perangkat lunak menjadi berita utama global, mulai dari paket npm yang dikompromikan, pustaka yang disisipi backdoor, hingga server CI yang dikhianati, proses build Bitcoin Core berdiri sebagai proyek disiplin yang tenang. Metodenya mungkin tampak lambat dan rumit dibanding kenyamanan tanpa gesekan dari “push to deploy,” tetapi itulah intinya. Keamanan tidaklah nyaman.

Untuk memahami sistem build Bitcoin Core, kita harus memahami:

• Filsafat Sistem Build Bitcoin Core
• Reproducible Builds (Build yang Dapat Direproduksi)
• Meminimalkan Dependensi
• Tidak Ada Pembaruan Otomatis
• Integrasi Berkelanjutan
• Adaptasi Berkelanjutan

Filsafat Sistem Build Bitcoin Core

Dalam hal desentralisasi Bitcoin, kebanyakan orang berfokus pada penambang, node, dan pengembang. Tetapi desentralisasi tidak berhenti pada peserta protokol. Desentralisasi juga mencakup cara perangkat lunak itu sendiri dibangun dan didistribusikan.

Salah satu prinsip dalam ekosistem Bitcoin adalah “jangan percaya, verifikasi.” Menjalankan node Anda sendiri adalah tindakan verifikasi, memeriksa setiap blok dan transaksi terhadap aturan konsensus. Tetapi sistem build itu sendiri memberi Anda kesempatan lain untuk memverifikasi, pada level perangkat lunaknya. Bitcoin adalah uang tanpa perantara tepercaya, dan Bitcoin Core bekerja untuk menjadi perangkat lunak tanpa pembangun tepercaya. Sistem build melakukan upaya besar untuk memastikan bahwa siapa pun, di mana pun, dapat secara independen merekonstruksi persis binary yang sama yang muncul di situs bitcoincore.org.

Filosofi ini ditelusuri kembali ke esai Ken Thompson tahun 1984 Reflections on Trusting Trust, yang memperingatkan bahwa bahkan kode sumber yang terlihat bersih pun tidak bisa dipercaya jika compiler yang membangun perangkat lunak tersebut ternyata juga dikompromikan. Para pengembang Bitcoin mengambil pelajaran itu dengan serius. Dalam kata-kata kontributor Bitcoin Core Michael Ford (fanquake):

“Reproducible builds sangat penting, karena tidak ada pengguna perangkat lunak kami yang seharusnya perlu mempercayai bahwa yang terkandung di dalamnya adalah apa yang kami katakan. Ini harus selalu bisa diverifikasi secara independen.”

Pernyataan yang merupakan tujuan teknis sekaligus bagian dari etos Bitcoin.

Di dunia keamanan, orang membahas “attack surfaces” (permukaan serangan). Sistem build Bitcoin Core memperlakukan proses build itu sendiri sebagai permukaan serangan yang harus diminimalkan dan dipertahankan.

Reproducible Builds: Verifikasi sampai ke paling bawah

Proses menghasilkan rilis Bitcoin Core dimulai dengan basis kode open-source di GitHub. Setiap perubahan bersifat publik. Setiap pull request ditinjau. Tetapi perjalanan dari kode yang mudah dibaca manusia ke perangkat lunak binary yang dapat dijalankan melibatkan compiler, pustaka pihak ketiga, dan sistem operasi yang juga merupakan vektor potensial untuk manipulasi, backdoor, atau kesalahan.

“Pihak ketiga yang tepercaya adalah lubang keamanan” – Nick Szabo (2001)

Untuk mengatasi kekhawatiran ini, arsitek Bitcoin Core merancang pipeline proses build menggunakan Guix, sebuah manajer paket yang dirancang untuk membuat lingkungan perangkat lunak yang dapat direproduksi dan deterministik.

Ketika sebuah rilis Bitcoin Core baru diberi tag, beberapa kontributor independen membangun binary dari nol menggunakan Guix. Setiap pembangun bekerja dalam lingkungan yang terisolasi yang menjamin toolchain yang identik, versi compiler, dan pustaka sistem. Jika semua pembangun menghasilkan output dengan bit yang identik, mereka tahu bahwa proses build itu deterministik.

Kontributor kemudian menandatangani binary yang dihasilkan secara kriptografis dan mempublikasikan tanda tangan tersebut di repositori GitHub terpisah ‘guix.sigs’ yang mencantumkan bukti/attestation ini untuk setiap rilis Bitcoin Core. Sebagian pembangun adalah pengembang Bitcoin Core, tetapi itu bukan persyaratan karena proses attestation terbuka untuk siapa pun dari publik. Faktanya, banyak kontributor non-kode secara rutin menyumbangkan tanda tangan.

Proses ini dikenal sebagai reproducible builds, dan menjadi penawar bagi “trusting trust” ala Thompson. Artinya, siapa pun dapat mengambil kode open-source, lingkungan Guix yang sama, dan secara independen memastikan bahwa binary resmi sesuai dengan apa yang mereka bangun sendiri. Sementara reproducible builds dapat memverifikasi bahwa perangkat lunak tersebut benar-benar representasi dari kode sumber perangkat lunak, kebenaran perangkat lunak diserahkan pada proses di sekelilingnya—seperti pengujian menyeluruh dan peninjauan kode.

Kebanyakan orang tidak akan pernah melakukan kompilasi penuh atau memeriksa manifest Guix atau membandingkan hash build. Mereka tidak perlu melakukannya. Keberadaan infrastruktur itu, dan orang-orang yang memeliharanya, memberi setiap pengguna fondasi kepercayaan yang diperoleh.

Binary resmi di bitcoincore.org bukan hanya “dihasilkan oleh para pemelihara Bitcoin Core”. Mereka adalah titik temu dari hasil keluaran puluhan pembangun independen. Yang akhirnya Anda unduh adalah yang dibangun dan diverifikasi oleh semua orang lain sebagai autentik.

Ini adalah verifikasi sampai ke paling bawah.

Meminimalkan Dependensi: Lebih sedikit yang Perlu Dipercaya

Reproducibility adalah satu sisi dari persamaan. Sisi lainnya adalah meminimalkan apa yang perlu direproduksi. Kode Bitcoin Core bukan satu-satunya kode yang dieksekusi saat menjalankan Bitcoin Core. Bitcoin Core juga mengandalkan kode dan pustaka pihak eksternal untuk mempercepat pengembangan dan meningkatkan produktivitas.

Dalam dekade terakhir, pengembang Bitcoin Core secara bertahap telah menghapus dependensi pihak ketiga yang tidak perlu dan kadang bermasalah ini, seperti OpenSSL dan MiniUPnP. Baik itu pustaka eksternal atau toolkit, dependensi ini menambah kompleksitas atau menyisipkan asumsi tersembunyi. Proyek seperti Boost dan Libevent, yang dulu menjadi “andalan” pada basis kode Core, secara bertahap digeser atau digantikan dengan alternatif yang lebih sederhana dan berdiri sendiri.

Kenapa? Karena setiap dependensi yang Anda warisi adalah risiko potensial pada rantai pasokan. Itu adalah lebih banyak kode yang tidak Anda tulis, tidak Anda audit, dan tidak bisa Anda kendalikan sepenuhnya. Mengurangi dependensi membuat sistem build lebih ramping, lebih aman, dan lebih mudah untuk diverifikasi.

Brink baru-baru ini menyoroti upaya ini dalam posting blog mereka “Minimizing Dependencies”[1], dengan mencatat bahwa ini bukan sekadar soal kesederhanaan, melainkan tentang menjaga keamanan dan otonomi proyek. Setiap dependensi yang dihapus berarti satu pihak eksternal lebih sedikit yang harus dipercayai oleh proyek, dan satu peluang backdoor yang lebih sedikit.

Tujuan akhirnya adalah menghasilkan binary yang sepenuhnya statis: executable yang berisi semua yang mereka butuhkan untuk berjalan, tanpa dependensi dinamis atau dependensi saat runtime. Sifat “self-containment” ini berarti tidak ada ketergantungan pada pustaka eksternal yang bisa berbeda antara satu sistem operasi dengan sistem operasi lainnya.

Dalam dunia di mana sebagian besar perangkat lunak tumbuh lebih berat dan semakin bergantung pada ekosistem paket terpusat, Bitcoin Core bergerak ke arah yang berlawanan: menuju minimalisme dan kemandirian.

Tidak Ada Pembaruan Otomatis

Pada kebanyakan perangkat lunak modern, pengguna dilindungi dari keputusan tentang versi perangkat lunak mana yang harus diperbarui, atau keputusan untuk sama sekali memperbarui perangkat lunak. Anda menginstal sebuah aplikasi, dan aplikasi itu diam-diam serta otomatis memperbarui dirinya ke versi terbaru di latar belakang. Meskipun ini nyaman, hal tersebut bertentangan dengan filosofi Bitcoin Core.

Bitcoin Core tidak pernah menyertakan pembaruan otomatis, dan para pengembang telah mengatakan bahwa mereka tidak akan pernah menyertakannya. Pembaruan otomatis memusatkan kekuatan. Mereka membentuk satu kelompok yang bisa mendorong (mungkin berbahaya) kode ke setiap node dalam jaringan. Ini persis jenis kontrol terpusat yang ingin dihindari Bitcoin. Dengan mewajibkan pengguna untuk secara manual mengunduh, memverifikasi, dan menginstal versi baru, Bitcoin Core memperkuat tanggung jawab individu dan persetujuan yang dapat diverifikasi.

Sistem build dan tidak adanya pembaruan otomatis adalah dua bagian dari prinsip yang sama. Hanya pelaksana node yang memutuskan apa yang harus dijalankan dan dapat memverifikasi bahwa perangkat lunak yang dijalankan adalah autentik.

Integrasi Berkelanjutan: Bergerak pelan dan perbaiki hal-hal

Di Silicon Valley, integrasi berkelanjutan dan continuous deployment (CI/CD) adalah ciri khas pengembangan perangkat lunak yang gesit. Kirim cepat. Iterasi lebih cepat. Biarkan otomatisasi mengurus sisanya.

Bitcoin Core mengambil pendekatan yang berbeda. Sistem CI-nya ada bukan untuk mempercepat deployment, melainkan untuk menjaga integritas. Build otomatis menguji konsistensi lintas platform. Sistem build Bitcoin Core dirancang untuk tidak bergantung pada perangkat keras dan sistem operasi sedapat mungkin. Proyek ini dapat membangun binary untuk Linux, macOS, dan Windows serta untuk banyak arsitektur termasuk x86_64, aarch64 (ARM), dan bahkan riscv64. Sistem integrasi berkelanjutan memastikan kompatibilitas ini sekaligus integritas perangkat lunak dengan melakukan ratusan pengujian untuk setiap perubahan yang diajukan.

Hasilnya adalah budaya di mana “continuous integration” berarti pengujian berkelanjutan, verifikasi, dan keamanan, bukan inovasi berkelanjutan.

Bergerak pelan dan perbaiki hal-hal.

Adaptasi Berkelanjutan: Apa kita sudah selesai?

Sistem build tidaklah statis. Para pengembang terus menyempurnakannya dengan mengurangi dependensi, meningkatkan build lintas arsitektur, dan mengeksplorasi masa depan build yang sepenuhnya statis dengan nol dependensi saat runtime.

Meskipun sistem build Bitcoin Core berupaya untuk determinisme, sistem build itu sendiri tidak bisa statis. Dunia tempat ia beroperasi terus berubah. Sistem operasi, compiler, pustaka, dan arsitektur perangkat keras semuanya mengalami perubahan. Setiap rilis baru macOS atau glibc, setiap penghapusan/penyusutan penggunaan flag compiler, atau munculnya arsitektur CPU baru menghadirkan ketidakcocokan yang halus dan harus ditangani. Sistem build yang dibiarkan diam akan, seiring waktu, berhenti bisa dibangun sama sekali.

Paradoks dari reproducible builds adalah bahwa reproducible builds memerlukan evolusi yang berkelanjutan agar tetap bisa direproduksi. Pengembang harus terus-menerus mengunci versi, menambal, dan kadang mengganti toolchain untuk mempertahankan determinisme di tengah latar perubahan yang terus bergerak. Menjaga keseimbangan antara stabilitas dan kemampuan beradaptasi ini adalah bagian dari ketahanan Bitcoin yang berkelanjutan.

Dapatkan salinan The Core Issue Anda hari ini!

Jangan lewatkan kesempatan Anda untuk memiliki The Core Issue — menampilkan artikel yang ditulis oleh banyak Pengembang Core yang menjelaskan proyek yang mereka kerjakan sendiri!

Artikel ini adalah Surat dari Editor yang tampil di edisi Print terbaru Bitcoin Magazine, The Core Issue. Kami membagikannya di sini sebagai tampilan awal atas gagasan yang dibahas di seluruh edisi.

[1]