Crypto · 4 min read · 3 views
Mesa Aktif di Mainnet Mina: Blok 90 Detik, zkApp Lebih Besar, dan Dampak Migrasinya
Mesa kini aktif di mainnet Mina dengan slot 90 detik, kapasitas zkApp lebih besar, dan Automode untuk hard fork. Simak dampaknya terhadap verification key, node, archive, serta langkah evaluasi aplikasi.
GD
I Gusti Agung Ganes Satsangga Dipa
Backend & Software Developer
# Pembukaan
Upgrade **Mesa** kini aktif di mainnet Mina Protocol. Hard fork ini memotong durasi slot dari 180 menjadi 90 detik, memperluas kapasitas zkApp, dan memperkenalkan jalur upgrade otomatis bagi block producer.
Perubahannya bukan sekadar “blok dua kali lebih cepat”. Developer perlu memahami batas state baru, verification key lama yang tidak lagi berlaku, serta dampak terhadap archive node dan indexer. Artikel ini membahas mekanisme Mesa dan langkah praktis untuk mengevaluasi aplikasi setelah upgrade.
---
## Daftar Isi
01. [Apa Itu Upgrade Mesa Mina?](#01--apa-itu-upgrade-mesa-mina)
02. [Mengapa Hal Ini Penting?](#02--mengapa-hal-ini-penting)
03. [Bagaimana Cara Mengevaluasi Dampaknya?](#03--bagaimana-cara-mengevaluasi-dampaknya)
04. [Kesalahan yang Sering Terjadi](#04--kesalahan-yang-sering-terjadi)
05. [Tips Tambahan](#05--tips-tambahan)
06. [Kesimpulan](#kesimpulan)
---
## 01 — Apa Itu Upgrade Mesa Mina?
Mesa adalah hard fork besar Mina yang tidak kompatibel mundur untuk software node. Menurut [dokumentasi resmi Mesa](https://docs.minaprotocol.com/network-upgrades/mesa), block producer, SNARK coordinator, archive node, Rosetta API node, dan seed node harus menjalankan rilis kompatibel agar tetap mengikuti jaringan.
Upgrade ini menggabungkan empat Mina Improvement Proposal. MIP6 mengurangi slot menjadi 90 detik; MIP7 menaikkan state on-chain per akun zkApp dari 8 menjadi 32 field element; MIP8 menaikkan batas event/action per transaksi dari 100 menjadi 1.024 field element; dan MIP9 melipatgandakan tiga kali batas account update dalam satu transaksi.
Slot adalah jendela waktu ketika blok dapat dibuat. [Spesifikasi MIP6](https://github.com/MinaProtocol/MIPs/blob/main/MIPS/mip-0006-slot-reduction-90s.md) juga menurunkan coinbase reward per blok dari 720 menjadi 360 MINA agar frekuensi blok yang berlipat tidak menggandakan laju emisi berdasarkan waktu.
> **Highlight:** Mesa meningkatkan kapasitas aplikasi tanpa mengubah upgrade menjadi “uang gratis”; reward per blok, kompatibilitas software, dan verification key ikut disesuaikan.
## 02 — Mengapa Hal Ini Penting?
Blok yang lebih sering membuat pengalaman transaksi lebih responsif. Kapasitas state dan account update yang lebih besar juga mengurangi kebutuhan memecah logika zkApp menjadi banyak akun atau transaksi. Namun, manfaat itu datang bersama pekerjaan migrasi.
Dampak konkretnya meliputi:
- zkApp dapat menyimpan empat kali lebih banyak field state langsung pada akunnya;
- event/action yang lebih besar mendukung alur aplikasi lebih kompleks dalam satu transaksi;
- semua zkApp harus di-*redeploy* karena protocol version bump membatalkan verification key Berkeley;
- archive database dan parser perlu menerima field serta jumlah operasi yang lebih banyak;
- block producer dapat memakai **Automode**, yang memilih binary sebelum dan sesudah fork melalui dispatcher.
Pengumuman [Mina Protocol](https://minaprotocol.com/blog/welcome-to-mesa) menegaskan Mesa sudah aktif dan blok diproduksi dua kali lebih sering. Itu meningkatkan kapasitas teoritis, tetapi throughput nyata tetap bergantung pada permintaan transaksi, kapasitas block producer, proof generation, dan kondisi jaringan.
## 03 — Bagaimana Cara Mengevaluasi Dampaknya?
### Step 01 — Identifikasi komponen yang terdampak
Pisahkan wallet pengguna, zkApp, node konsensus, archive database, Rosetta integration, dan indexer. Wallet biasa tidak menjalankan daemon, tetapi tooling yang mengunci format transaksi atau versi protokol mungkin tetap perlu diperbarui.
### Step 02 — Uji kontrak dan data pipeline
Kompilasi dengan o1js yang kompatibel, redeploy verification key, lalu jalankan transaksi end-to-end. Untuk archive dan Rosetta, uji schema baru, operasi berulang, serta tipe operasi `account_creation_fee_via_zkapp`.
| Area | Perubahan Mesa | Pemeriksaan utama |
|---|---|---|
| Konsensus | slot 180 → 90 detik | sinkronisasi, uptime, produksi blok |
| zkApp state | 8 → 32 field | layout state dan redeploy |
| Event/action | 100 → 1.024 field | ukuran payload dan parser |
| Account update | batas menjadi 3× | operasi, fee, dan indexing |
### Step 03 — Pantau setelah migrasi
Bandingkan latensi konfirmasi, kegagalan proof, chain tip, peer count, penggunaan CPU/RAM, dan lag archive. [Panduan contoh resmi](https://docs.minaprotocol.com/network-upgrades/mesa/upgrade-steps/examples) menyatakan state serta saldo akun lama terbawa, tetapi zkApp tidak dapat memproses transaksi sampai verification key yang kompatibel di-*redeploy*.
## 04 — Kesalahan yang Sering Terjadi
> ⚠️ **Kesalahan #1 — Menganggap semua zkApp langsung siap**
> State lama tetap ada, tetapi verification key Berkeley tidak berlaku pada Mesa. Redeploy dan uji transaksi sebelum membuka kembali layanan.
> ⚠️ **Kesalahan #2 — Menyamakan slot 90 detik dengan finalitas pasti 90 detik**
> Slot lebih pendek meningkatkan frekuensi peluang blok, bukan menjamin setiap transaksi masuk atau final pada waktu yang identik.
> ⚠️ **Kesalahan #3 — Hanya memperbarui daemon**
> Archive schema, Rosetta parser, monitoring, dan asumsi jumlah operasi juga dapat berubah. Uji stack secara end-to-end.
## 05 — Tips Tambahan
**Tip 01 — Jangan hard-code batas lama.** Ambil konstanta dari library dan versi protokol yang kompatibel agar aplikasi tidak diam-diam memakai batas Berkeley.
**Tip 02 — Simpan jalur rollback aplikasi.** Konfigurasi, image, dan migration script perlu terversi, meski node produksi tidak boleh kembali mengikuti aturan konsensus lama.
**Tip 03 — Ukur kapasitas nyata.** Pantau p50/p95 konfirmasi, proof time, dan lag indexer; klaim “dua kali lebih cepat” tidak menggantikan observasi workload sendiri.
## Kesimpulan
Mesa mempercepat ritme blok Mina sekaligus memberi ruang lebih besar bagi zkApp melalui state, event/action, dan account update yang diperluas. Automode juga mengurangi koordinasi manual untuk block producer saat hard fork.
Bagi pengguna biasa, perubahan ini umumnya tidak membutuhkan tindakan. Bagi developer dan operator, prioritasnya adalah redeploy verification key, memperbarui node dan tooling, memigrasikan data pipeline, lalu memantau performa aktual setelah upgrade.
*Disclaimer: Artikel ini bersifat informatif dan bukan nasihat keuangan atau rekomendasi investasi.*
---
## Sumber
- [Welcome to Mesa: Mina’s Latest Upgrade — Mina Protocol](https://minaprotocol.com/blog/welcome-to-mesa) — konfirmasi aktivasi mainnet dan ringkasan perubahan.
- [Mesa Upgrade — Mina Documentation](https://docs.minaprotocol.com/network-upgrades/mesa) — cakupan MIP, kompatibilitas node, Automode, dan batas baru.
- [MIP6: Reduce Slot Time to 90s — MinaProtocol/MIPs](https://github.com/MinaProtocol/MIPs/blob/main/MIPS/mip-0006-slot-reduction-90s.md) — spesifikasi slot, reward, dan alasan teknis.
- [Mesa Upgrade Examples — Mina Documentation](https://docs.minaprotocol.com/network-upgrades/mesa/upgrade-steps/examples) — konsekuensi migrasi zkApp dan verification key.
GD
Tentang Penulis — Ganes Satsangga
Backend Developer berpengalaman membangun aplikasi web, sistem ERP/CMS, integrasi API, dan database menggunakan Laravel, PHP, dan Go.
