TL;DR: Istniejący paradygmat aktualizacji programów Solana to katastrofa. Najniebezpieczniejszą rzeczą w pisaniu kodu smart kontraktów jest to, że modele danych programów są w zasadzie zablokowane po wdrożeniu. W tradycyjnym inżynierii oprogramowania API klienta jest oddzielone od backendu. Możesz niewidocznie zmieniać schemat backendu lub dodawać migracje do bazy danych. W programowaniu Solana możesz próbować zabezpieczyć kontrakt na przyszłość poprzez: - Dodawanie wypełnienia struktury i liczenie na to, że w danych konta będzie wystarczająco dużo pustych bitów na przyszłe zmiany - Wymaganie od użytkowników ręcznego podpisania migracji stanu aplikacji (okropne UX) - Wdrażanie działań administracyjnych na poziomie aplikacji w celu migracji schematów Zauważ, że wszystkie powyższe mają potencjał do złamania kompozycyjności na poziomie VM. Wymagają również złożonej i podatnej na błędy logiki, aby bezpiecznie je wykonać. Wprowadza to nie tylko ryzyko logicznych danych, ale także ryzyko zarządzania kluczami. Jednym z argumentów jest nigdy nie zmieniać kodu po wdrożeniu. W końcu istniejący framework sprawia, że modyfikacja istniejących formatów danych jest niezwykle trudna i niebezpieczna. Jednak nawet jeśli niezmienność jest pożądana, jest naiwne i lekkomyślne myśleć, że nie ma katastrofalnych błędów do naprawienia lub krytycznych funkcji do dodania w przyszłości (niektóre z nich mogą wymagać zmian w połączeniach). Firmy budujące na tym stosie są zmuszone wybierać między bezpieczeństwem, prędkością a jakością. Dziś narzędzia umożliwiające utrzymanie i ciągły rozwój wystarczająco złożonego smart kontraktu są nieistniejące. Oto niektóre z funkcji, które rozważałbym, gdybym budował to środowisko od podstaw: - Powinny istnieć oddzielne API w VM do odczytu i zapisu danych konta. Umożliwia to zmiany schematu bez łamania formatu połączenia zarówno dla konsumentów on-chain, jak i off-chain. - Niektóre (optymalne) funkcje administracyjne smart kontraktów powinny istnieć na poziomie systemu, a nie na poziomie aplikacji. - Przy wykonywalnej aktualizacji powinno jednocześnie odbywać się opcjonalne atomowe migracje kont należących do tego programu. Nawet jeśli celem jest niezmienność, budowanie narzędzi na poziomie systemu, aby umożliwić bezpieczne aktualizacje oprogramowania, jest kluczowe dla aplikacji konsumenckich z ewoluującym stanem. Obecny system jest tak kruchy, że najlepsza rada dla tych deweloperów to nigdy nie dotykać schematów on-chain, chyba że naprawdę wiedzą, co robią.