TL;DR: Het bestaande paradigma voor het upgraden van Solana-programma's is een ramp. Het gevaarlijkste aan het schrijven van smart contractcode is dat de programmagegevensmodellen effectief vergrendeld zijn na implementatie. In traditionele softwareontwikkeling is de client-API losgekoppeld van de backend. Je kunt onzichtbaar een backend-schema wijzigen of migraties aan een database toevoegen. In Solana-programmering kun je proberen een contract toekomstbestendig te maken door: - Struct-padding toe te voegen en te hopen dat er genoeg lege bits in de accountgegevens zijn voor toekomstige wijzigingen - Gebruikers te verplichten handmatig te ondertekenen om de applicatiestatus te migreren (vreselijke gebruikerservaring) - Applicatieniveau-beheeracties te implementeren om schema's te migreren Let op dat al het bovenstaande het potentieel heeft om VM-niveau samenhang te breken. Ze vereisen ook complexe en foutgevoelige logica om veilig uit te voeren. Het introduceert niet alleen logisch datarisico, maar ook risico op sleutelbeheer. Een argument is om de code na implementatie nooit te wijzigen. Tenslotte maakt het bestaande kader het extreem moeilijk om bestaande gegevensformaten veilig te wijzigen. Echter, zelfs als onveranderlijkheid wenselijk is, is het naïef en roekeloos om te denken dat er geen catastrofale bugs zijn om op te lossen of kritieke functies om in de toekomst toe te voegen (sommige daarvan kunnen draadwijzigingen vereisen). Bedrijven die op deze stack bouwen, worden gedwongen te kiezen tussen veiligheid, snelheid en kwaliteit. Vandaag de dag zijn de tools om het onderhoud en de continue ontwikkeling van een voldoende complex smart contract mogelijk te maken niet aanwezig. Hier zijn enkele van de functies die ik zou overwegen op te nemen als ik deze omgeving vanaf de basis zou bouwen: - Er zouden aparte API's in de VM moeten zijn om accountgegevens te lezen en te schrijven. Dit maakt schemawijzigingen mogelijk zonder het draadformaat voor zowel on-chain als off-chain consumenten te breken. - Sommige (opt-in) administratieve smart contractfuncties zouden op systeemniveau moeten bestaan, niet op applicatieniveau. - Bij uitvoerbare upgrades zou er tegelijkertijd een optionele atomische migratie van accounts die door dat programma worden beheerd moeten zijn. Zelfs als het doel onveranderlijkheid is, is het cruciaal om systeemniveau-tools te bouwen om veilige software-upgrades mogelijk te maken voor consumentenapplicaties met een evoluerende status. Het huidige systeem is zo kwetsbaar dat het beste advies voor deze ontwikkelaars is om nooit on-chain schema's aan te raken, tenzij ze echt weten wat ze doen.

Goede technologie, het is krankzinnig dat het 5 jaar heeft geduurd om hier te komen @solana 😭

De definitie van DEX is in de loop der jaren echt geëvolueerd. 2021: Matching wordt uitgevoerd en gevalideerd op een wereldwijd gedistribueerd netwerk. 2025: Stort tokens op Solana, Arbitrum of BSC, en de beurs zal dit registreren in een SQL-tabel. Matching vindt plaats in ap-northeast-1.