Masalah Inti: Di Bawah Biner, Memverifikasi Kepercayaan

Ketika kebanyakan orang mengunduh Bitcoin Core, interaksi mereka dengan sistem build selesai dalam beberapa klik. Mereka mengambil file binary eksekutabel dari perangkat lunak tersebut, memverifikasi tanda tangan (semoga!), dan mulai menjalankan node Bitcoin. Apa yang langsung mereka lihat adalah perangkat lunak yang berjalan. Apa yang tidak mereka lihat adalah sistem build dan proses ekstensif yang menghasilkan perangkat lunak tersebut. Sebuah sistem build yang mewakili prinsip-prinsip desentralisasi, transparansi, dan verifikasi Bitcoin.

Di balik unduhan itu tersembunyi bertahun-tahun pekerjaan rekayasa yang dirancang untuk menjawab satu pertanyaan sederhana: “Mengapa siapa pun harus mempercayai perangkat lunak ini?” Jawabannya adalah: mereka tidak perlu. Anda harus bisa memverifikasi.

Di saat serangan rantai pasokan perangkat lunak menjadi berita utama global, mulai dari paket npm yang dikompromikan, pustaka yang disusupi backdoor, server CI yang nakal, proses build Bitcoin Core berdiri sebagai proyek disiplin yang tenang. Metodenya mungkin terlihat lambat dan rumit dibandingkan kenyamanan tanpa hambatan dari “push to deploy,” tetapi itu intinya. Keamanan tidak nyaman.

Untuk memahami sistem build Bitcoin Core, kita harus memahami:

• Filosofi Sistem Build Bitcoin Core
• Reproducible Builds
• Meminimalkan Ketergantungan
• Tanpa Pembaruan Otomatis
• Integrasi Berkelanjutan
• Adaptasi Berkelanjutan

Filosofi Sistem Build Bitcoin Core

Ketika berbicara tentang desentralisasi Bitcoin, kebanyakan orang fokus pada penambang, node, dan pengembang. Tetapi desentralisasi tidak berhenti pada peserta protokol. Itu meluas ke cara perangkat lunak itu sendiri dibangun dan didistribusikan.

Salah satu prinsip dalam ekosistem Bitcoin adalah “jangan percaya, verifikasi.” Menjalankan node sendiri adalah tindakan verifikasi, memeriksa setiap blok dan transaksi sesuai aturan konsensus. Tetapi sistem build itu sendiri memberi Anda peluang lain untuk memverifikasi, di tingkat perangkat lunak. Bitcoin adalah uang tanpa perantara terpercaya dan Bitcoin Core berusaha menjadi perangkat lunak tanpa pembangun terpercaya. Sistem build berusaha keras memastikan bahwa siapa saja, di mana saja, dapat secara independen membuat ulang binary yang sama persis seperti yang muncul di situs bitcoincore.org.

Filosofi ini berakar dari esai Ken Thompson tahun 1984 Reflections on Trusting Trust, yang memperingatkan bahwa bahkan kode sumber yang tampak bersih pun tidak bisa dipercaya jika compiler yang membangun perangkat lunak tersebut sendiri telah dikompromikan. 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 harus mempercayai bahwa isi di dalamnya adalah apa yang kami katakan. Ini harus selalu dapat diverifikasi secara independen.”

Sebuah pernyataan yang sekaligus menjadi tujuan teknis dan bagian dari etos Bitcoin.

Dalam dunia keamanan, orang berbicara tentang “attack surfaces.” Sistem build Bitcoin Core memperlakukan proses build itu sendiri sebagai permukaan serangan yang harus diminimalkan dan dilindungi.

Reproducible Builds: Verifikasi sampai ke dasar

Proses menghasilkan rilis Bitcoin Core dimulai dari basis kode sumber terbuka di GitHub. Setiap perubahan bersifat publik. Setiap permintaan tarik (pull request) ditinjau. Tetapi perjalanan dari kode yang dapat dibaca manusia menjadi perangkat lunak binary yang dapat dijalankan melibatkan compiler, pustaka pihak ketiga, dan sistem operasi yang sendiri bisa menjadi vektor manipulasi, backdoor, atau kesalahan.

“Pihak ketiga yang dipercaya 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 menciptakan lingkungan perangkat lunak yang reproducible dan deterministik.

Ketika rilis Bitcoin Core baru ditandai, beberapa kontributor independen membangun binary dari awal menggunakan Guix. Setiap pembangun bekerja dalam lingkungan terisolasi yang menjamin kesamaan alat, versi compiler, dan pustaka sistem. Jika semua pembangun menghasilkan output yang identik, mereka tahu bahwa build tersebut deterministik.

Kontributor kemudian menandatangani secara kriptografi binary yang dihasilkan dan mempublikasikan tanda tangan tersebut di repositori GitHub terpisah ‘guix.sigs’ yang mencantumkan attestasi ini untuk setiap rilis Bitcoin Core. Beberapa pembangun adalah pengembang Bitcoin Core, tetapi ini bukan keharusan karena proses attestasi terbuka untuk siapa saja dari publik. Bahkan, banyak kontributor non-kode secara rutin menyumbangkan tanda tangan.

Proses ini dikenal sebagai reproducible builds, dan ini adalah antidote terhadap “trusting trust” Thompson. Artinya, siapa saja dapat mengambil kode sumber terbuka, lingkungan Guix yang sama, dan secara independen memastikan bahwa binary resmi cocok dengan yang mereka bangun sendiri. Meskipun reproducible builds dapat memverifikasi bahwa perangkat lunak adalah representasi asli dari kode sumbernya, keakuratan perangkat lunak diserahkan pada proses pengujian menyeluruh dan review kode.

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

Binary resmi di bitcoincore.org bukan hanya “diproduksi oleh pemelihara Bitcoin Core.” Mereka adalah hasil dari puluhan pembangun independen. Apa yang akhirnya Anda unduh adalah apa yang dibangun dan diverifikasi oleh semua orang lain agar otentik.

Ini adalah verifikasi sampai ke dasar.

Meminimalkan Ketergantungan: Lebih Sedikit yang Perlu Dipercaya

Reproduksibilitas adalah satu sisi dari koin. Sisi lainnya adalah meminimalkan apa yang perlu direproduksi. Kode Bitcoin Core bukan satu-satunya kode yang dijalankan saat menjalankan Bitcoin Core. Bitcoin Core juga bergantung pada kode dan pustaka pihak ketiga eksternal untuk mempercepat pengembangan dan produktivitas.

Selama dekade terakhir, pengembang Bitcoin Core secara bertahap mengurangi ketergantungan pihak ketiga yang tidak perlu dan kadang bermasalah, seperti OpenSSL dan MiniUPnP. Baik itu pustaka eksternal maupun toolkit, ketergantungan ini menambah kompleksitas atau menyisipkan asumsi tersembunyi. Proyek seperti Boost dan Libevent, yang dulu menjadi bagian utama dari kode dasar, secara bertahap dihapus atau digantikan dengan alternatif yang lebih sederhana dan mandiri.

Mengapa? Karena setiap ketergantungan yang Anda warisi adalah potensi risiko rantai pasokan. Itu adalah kode yang tidak Anda tulis, tidak Anda audit, dan tidak bisa Anda kendalikan sepenuhnya. Mengurangi ketergantungan membuat sistem build lebih ramping, lebih aman, dan lebih mudah diverifikasi.

Brink baru-baru ini menyoroti upaya ini dalam posting blog “Minimizing Dependencies”[1], mencatat bahwa ini bukan hanya soal kesederhanaan, tetapi tentang menjaga keamanan dan otonomi proyek. Setiap ketergantungan yang dihapus adalah satu pihak eksternal yang harus dipercaya dan satu potensi backdoor yang berkurang.

Tujuan akhirnya adalah menghasilkan binary yang sepenuhnya statis: executable yang berisi semua yang mereka butuhkan untuk berjalan, tanpa ketergantungan dinamis atau runtime. Mandiri ini berarti tidak bergantung pada pustaka eksternal yang bisa berbeda dari satu sistem operasi ke sistem operasi lain.

Di dunia di mana sebagian besar perangkat lunak menjadi lebih berat dan lebih bergantung pada ekosistem paket terpusat, Bitcoin Core bergerak ke arah sebaliknya: menuju minimalisme dan kemandirian.

Tanpa Pembaruan Otomatis

Dalam sebagian besar perangkat lunak modern, pengguna dilindungi dari keputusan tentang versi perangkat lunak apa yang harus diperbarui, atau keputusan untuk memperbarui perangkat lunak sama sekali. Anda menginstal aplikasi, dan secara diam-diam serta otomatis memperbaruinya ke versi terbaru di latar belakang. Meskipun ini nyaman, ini bertentangan dengan filosofi Bitcoin Core.

Bitcoin Core tidak pernah menyertakan pembaruan otomatis, dan pengembang mengatakan tidak akan pernah. Pembaruan otomatis memusatkan kekuasaan. Mereka menciptakan satu kelompok yang dapat mendorong kode (berpotensi berbahaya) ke setiap node di jaringan. Ini adalah jenis kontrol terpusat yang Bitcoin dirancang untuk hindari. 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 ketidakadaan pembaruan otomatis adalah dua bagian dari prinsip yang sama. Hanya pengelola node yang memutuskan apa yang dijalankan dan dapat memverifikasi bahwa perangkat lunak yang dijalankan adalah otentik.

Integrasi Berkelanjutan: Lambatkan dan perbaiki

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

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

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

Lambatkan dan perbaiki.

Adaptasi Berkelanjutan: Apakah kita sudah selesai?

Sistem build tidak statis. Pengembang terus menyempurnakannya dengan mengurangi ketergantungan, meningkatkan build lintas arsitektur, dan menjajaki masa depan build statis penuh tanpa ketergantungan runtime.

Meskipun sistem build Bitcoin Core berusaha untuk determinisme, sistem itu sendiri tidak bisa statis. Dunia tempat ia beroperasi terus berubah. Sistem operasi, compiler, pustaka, dan arsitektur perangkat keras semuanya mengalami perubahan. Rilis baru macOS atau glibc, setiap deprecate flag compiler, atau munculnya arsitektur CPU baru memperkenalkan ketidakcocokan halus yang harus diatasi. Sistem build yang diam akan, seiring waktu, berhenti bisa membangun sama sekali.

Paradoks dari reproducible builds adalah bahwa mereka membutuhkan evolusi berkelanjutan agar tetap dapat direproduksi. Pengembang harus terus-menerus menahan, memperbaiki, dan kadang mengganti toolchain untuk menjaga determinisme di tengah perubahan yang terus berlangsung. Menjaga keseimbangan antara stabilitas dan adaptabilitas ini adalah bagian dari ketahanan berkelanjutan Bitcoin.

Dapatkan salinan The Core Issue hari ini!

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

Penulisan ini adalah Surat dari Editor yang tampil di edisi cetak terbaru Bitcoin Magazine, The Core Issue. Kami membagikannya di sini sebagai gambaran awal tentang ide-ide yang dieksplorasi di seluruh edisi lengkap.

[1]