Fase 0 · Fondasi Kriptografi & Struktur Data

Kriptografi asimetris — ECDSA & secp256k1

Di Web2, siapa kamu ditentukan server lewat sesi dan password yang bisa direset. Di Web3, siapa kamu ditentukan matematika — sepasang kunci yang kamu buat sendiri, dan yang tidak bisa dipulihkan siapa pun kalau hilang.

Sumber asli ethereum.org Resmi Rangkuman ~7 menit baca

Intisari

Akun Ethereum adalah pasangan private key (256-bit acak) dan public key yang diturunkan darinya lewat kurva eliptik secp256k1 — bukan pasangan yang didaftarkan ke server mana pun.
Address adalah 20 byte terakhir dari keccak256(public_key) — turunan, bukan input independen.
Signing (ECDSA) membuktikan kamu memegang private key tanpa pernah mengirimkannya — inilah dasar seluruh model trust di blockchain.
Kehilangan private key = kehilangan aset selamanya. Tidak ada proses "lupa password" — ini bukan kekurangan, ini konsekuensi langsung dari tidak adanya otoritas pusat.
Jangan pernah menyimpan private key produksi di kode, .env plain text, atau log — dibahas tuntas di Fase 4.

Dari mana address berasal

Di database tradisional, ID pengguna dibuat server — auto-increment, UUID, apa pun yang dipilih backend-mu. Di Ethereum, address dibuat lewat rantai turunan matematis yang bisa dihitung siapa saja, di mana saja, tanpa perlu terhubung ke jaringan sama sekali:

Private key: 256-bit angka acak yang dipilih secara kriptografis aman. Ini rahasianya.
Public key: diturunkan dari private key lewat perkalian titik pada kurva eliptik secp256k1 — operasi satu arah, sama seperti hash, tapi berbasis aljabar kurva, bukan hash.
Address: 20 byte terakhir dari keccak256(public_key), ditulis heksadesimal berawalan 0x.

Kenapa ini penting dipahami, bukan cuma dihafal: setiap langkah di atas bisa dihitung ulang dan diverifikasi siapa saja tanpa server pusat. Tidak ada tabel users yang menyimpan pemetaan address ke identitas — address itu sendiri adalah buktinya, selama kamu bisa menandatangani sesuatu dengan private key yang bersesuaian.

secp256k1 — kenapa bukan kurva "biasa"

TLS/HTTPS yang kamu pakai sehari-hari umumnya memakai kurva P-256 (secp256r1) atau Curve25519. Bitcoin dan Ethereum memilih secp256k1 — kurva yang parameternya dipilih secara "dapat diverifikasi" (bukan angka yang diklaim acak oleh satu badan tunggal), sehingga lebih tepercaya untuk sistem tanpa otoritas pusat. Konsekuensi praktisnya untuk engineer: pustaka TLS standar (mis. java.security dengan provider default) tidak selalu menyertakan secp256k1 — kamu butuh Bouncy Castle di Java, atau pustaka secp256k1 khusus di PHP.

Signing: membuktikan tanpa membocorkan

Ini inti dari trustless: bagaimana node lain yakin transaksimu benar-benar berasal dari pemegang private key yang sah, padahal private key itu tidak pernah dikirim ke mana pun?

1. Kamu hash pesan/transaksi          → h = keccak256(data)
2. Kamu tanda tangani hash itu        → (v, r, s) = sign(h, privateKey)
3. Kamu kirim data + tanda tangan     → node menerima (data, v, r, s)
4. Node memverifikasi                 → recover(h, v, r, s) == address pengirim?

Langkah 4 yang istimewa: dari tanda tangan (v, r, s) dan hash pesan, node bisa menghitung ulang address penandatangan — tanpa pernah tahu private key-nya. Ini yang membuat setiap transaksi Ethereum tidak perlu menyertakan public key secara eksplisit; ia dipulihkan dari tanda tangannya sendiri.

Tanda tangan di luar rantai (Java & PHP)

import org.web3j.crypto.ECKeyPair;
import org.web3j.crypto.Keys;
import org.web3j.crypto.Sign;

ECKeyPair keyPair = Keys.createEcKeyPair();          // private + public key baru
String address = "0x" + Keys.getAddress(keyPair);   // diturunkan, bukan diberi

byte[] pesan = "otorisasi transaksi".getBytes();
Sign.SignatureData tandaTangan = Sign.signMessage(pesan, keyPair);

Ini kode contoh untuk belajar, bukan pola produksi. createEcKeyPair() membuat private key baru di memori proses Java-mu. Di sistem nyata, private key yang mengendalikan dana tidak boleh pernah ada sebagai variabel biasa di RAM aplikasi — ia harus tinggal di HSM atau KMS. Detailnya di Fase 4.

Wallet: antarmuka, bukan kotak penyimpanan terpusat

Jenis	Private key disimpan di	Cocok untuk
Hot wallet (MetaMask, dst.)	Browser/perangkat, terenkripsi dengan password	Interaksi sehari-hari, jumlah kecil
Hardware wallet (Ledger, dst.)	Chip aman terpisah, tidak pernah keluar perangkat	Penyimpanan jangka panjang
Cloud KMS (AWS KMS, dst.)	Modul kriptografi terkelola, signing tanpa key pernah "keluar"	Backend/service yang butuh sign otomatis
Multi-signature (Gnosis Safe)	Tersebar — butuh N dari M tanda tangan	Dana treasury, keputusan administratif

Latihan: buat key pair baru dengan web3j atau OpenSSL (openssl ecparam -name secp256k1 -genkey), turunkan address-nya secara manual (public key → keccak256 → 20 byte terakhir), lalu bandingkan hasilnya dengan yang ditampilkan MetaMask saat kamu impor private key yang sama ke akun testnet. Kalau hasilnya sama, kamu baru saja membuktikan sendiri bahwa address bukan diberi — ia dihitung.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.