TL; DR: Paradigma yang ada untuk meningkatkan program Solana adalah bencana. Hal yang paling berbahaya tentang menulis kode kontrak pintar adalah bahwa model data program secara efektif dikunci setelah penerapan. Dalam SWE tradisional, API klien dipisahkan dari backend. Anda dapat mengubah skema backend secara tidak terlihat atau menambahkan migrasi ke database. Dalam pemrograman Solana, Anda dapat mencoba membuktikan kontrak di masa depan dengan: - Menambahkan padding struct dan berharap ada cukup bit kosong dalam data akun untuk perubahan di masa mendatang - Mengharuskan pengguna untuk menandatangani secara manual untuk memigrasikan status aplikasi (UX yang mengerikan) - Menerapkan tindakan admin tingkat aplikasi untuk memigrasikan skema Perhatikan bahwa semua hal di atas berpotensi merusak composability tingkat VM. Mereka juga membutuhkan logika yang kompleks dan rawan kesalahan untuk mengeksekusi dengan aman. Ini tidak hanya memperkenalkan risiko data logis, tetapi juga risiko manajemen kunci. Salah satu argumennya adalah untuk tidak pernah mengubah kode setelah penerapan. Lagi pula, kerangka kerja yang ada membuatnya sangat sulit untuk memodifikasi format data yang ada dengan aman. Namun, bahkan jika kekekalan diinginkan, adalah naif dan sembrono untuk berpikir bahwa tidak ada bug bencana yang harus diperbaiki atau fitur penting untuk ditambahkan di masa mendatang (beberapa di antaranya mungkin memerlukan perubahan kabel). Bisnis yang membangun di atas tumpukan ini dipaksa untuk memilih antara keamanan, kecepatan, dan kualitas. Saat ini, alat untuk memungkinkan pemeliharaan dan pengembangan berkelanjutan dari kontrak pintar yang cukup kompleks tidak ada. Berikut adalah beberapa fitur yang akan saya pikirkan untuk disertakan jika saya membangun lingkungan ini dari prinsip pertama: - Harus ada API terpisah di VM untuk membaca dan menulis data akun. Hal ini memungkinkan perubahan skema tanpa memutus format kabel untuk konsumen on-chain dan off-chain. - Beberapa fungsi kontrak pintar administratif (opt-in) harus ada di tingkat sistem, bukan tingkat aplikasi. - Pada peningkatan yang dapat dieksekusi, secara bersamaan harus ada migrasi atom opsional dari akun yang dimiliki oleh program tersebut. Bahkan jika tujuannya adalah keabadian, membangun perkakas tingkat sistem untuk memungkinkan peningkatan perangkat lunak yang aman sangat penting untuk aplikasi konsumen dengan keadaan yang berkembang. Sistem saat ini sangat rapuh sehingga saran terbaik untuk pengembang ini adalah jangan pernah menyentuh skema on-chain kecuali mereka benar-benar tahu apa yang mereka lakukan.

Teknologi yang bagus, gila bahwa kami membutuhkan waktu 5 tahun untuk sampai di sini @solana 😭

Definisi DEX benar-benar berkembang selama bertahun-tahun. 2021: Pencocokan dijalankan dan divalidasi pada jaringan yang didistribusikan secara global. 2025: Setor token di Solana, Arbitrum, atau BSC, dan bursa akan mencatatnya dalam tabel SQL. Pencocokan terjadi di ap-northeast-1.