TL; DR: Nykyinen Solana-ohjelmien päivitysparadigma on katastrofi. Älysopimuskoodin kirjoittamisen vaarallisin asia on, että ohjelman datamallit lukitaan käytännössä käyttöönoton jälkeen. Perinteisessä ohjelmistokehityksessä asiakasrajapinta on irrotettu taustajärjestelmästä. Voit näkymättömästi muuttaa taustaskeemaa tai lisätä migraatioita tietokantaan. Solanan ohjelmoinnissa voit yrittää varmistaa sopimuksen tulevaisuuden tavoin: - Rakennetäytteen lisääminen ja toivominen, että tilitiedoissa on tarpeeksi tyhjiä bittejä tulevia muutoksia varten - Käyttäjien manuaalinen allekirjoittaminen sovelluksen tilan siirtämiseksi (huono käyttökokemus) - Sovellustason ylläpitäjätoimintojen toteuttaminen skeemien siirtämiseksi Huomaa, että kaikki edellä mainitut voivat rikkoa virtuaalikoneen tason komposittivuuden. Ne vaativat myös monimutkaista ja virhealtista logiikkaa turvalliseen suoritukseen. Se ei ainoastaan tuo mukaan loogista datariskiä, vaan myös keskeisen hallinnan riskin. Yksi perustelu on, ettei koodia kannata koskaan muuttaa käyttöönoton jälkeen. Loppujen lopuksi olemassa oleva kehys tekee olemassa olevien tietomuotojen turvallisesta muokkaamisesta erittäin vaikeaa. Kuitenkin, vaikka muuttumattomuus olisi toivottavaa, on naiivia ja uhkarohkeaa ajatella, ettei tulevaisuudessa olisi katastrofaalisia bugeja korjattavana tai kriittisiä ominaisuuksia lisättävänä (joista osa saattaa vaatia johdonvaihtoja). Tämän pinon päälle rakentavat yritykset joutuvat valitsemaan turvallisuuden, nopeuden ja laadun välillä. Nykyään työkaluja, jotka mahdollistaisivat riittävän monimutkaisen älysopimuksen ylläpidon ja jatkuvan kehityksen, ovat olemattomia. Tässä on joitakin ominaisuuksia, joita ajattelisin sisällyttää, jos rakentaisin tämän ympäristön perusperiaatteista: - VM:ssä pitäisi olla erilliset API:t tilitietojen lukemiseen ja kirjoittamiseen. Tämä mahdollistaa skeeman muutokset rikkomatta johtomuotoa sekä ketjun että ketjun ulkopuolisille käyttäjille. - Jotkin (valinnaiset) hallinnolliset älysopimustoiminnot tulisi olla järjestelmätasolla, eivät sovellustasolla. - Suoritettavan päivityksen yhteydessä tulisi samanaikaisesti olla valinnainen atomisiirto kyseisen ohjelman omistamille tileille. Vaikka tavoitteena olisi muuttumattomuus, järjestelmätason työkalujen rakentaminen turvallisten ohjelmistopäivitysten mahdollistamiseksi on kriittistä kuluttajasovelluksissa, joissa tila kehittyy. Nykyinen järjestelmä on niin hauras, että paras neuvo näille kehittäjille on olla koskematta ketjun skeemoihin, elleivät he todella tiedä mitä tekevät.

Hyvää teknologiaa, uskomatonta että kesti viisi vuotta päästä tänne @solana 😭

DEX:n määritelmä on todella kehittynyt vuosien varrella. 2021: Täsmäytys suoritetaan ja validoidaan maailmanlaajuisesti hajautetussa verkossa. 2025: Talleta tokeneita Solanaan, Arbitrumiin tai BSC:hen, ja pörssi tallentaa ne SQL-taulukkoon. Vastaavuus tapahtuu ap-koillis-1.