Move Gemini: Miten Sui ja Aptos Challenge Blockchain maisema

Introduction

Viime aikoina markkinat ovat viilentyneet huomattavasti, mikä on saanut jopa alan veteraanit kyseenalaistamaan alan tarkoituksen. Haluaisin jakaa joitakin henkilökohtaisia ajatuksiani: Uskon, että monet menneisyyden suurista visioista ”kumottiin”, koska ne eivät koskaan olleet alusta alkaen loogisesti johdonmukaisia.

Muut kuin rahoitusalan dappit yrittivät usein korostaa hajauttamista peittääkseen sen tosiasian, että itse tuotteet eivät olleet tarpeeksi hyviä. Todellisuudessa ne pyytävät minua epäluottamaan Googleen, Twitteriin ja YouTubeen ja sen sijaan uskomaan, että niiden moninkertaisten allekirjoitusten lompakot ja yhden palvelimen kokoonpanot ovat turvallisia.

Monia näkyjä ei kumottu, mutta niitä ei koskaan todella testattu. Uskon edelleen, että vaikka useimmat visiot eivät olekaan suuria, niillä on merkitystä – ne saattavat vain tarvita tukevan perustan. Lopulta voidaan tarjota ainakin yksi hajauttaminen tai Web2:een verrattavissa oleva käyttäjäkokemus.

Aivan kuten TON ja Solana olivat aikoinaan aliarvioituja, mutta ovat nyt saavuttamassa edeltäjiään monilta osin. Sovelluksia tukevat julkiset ketjut tarvitsevat innovaatiota, joka joka syklissä ajaa alan kehitystä. Tänään tutustumme siis julkisten ketjujen tyyppiin, joka on pitkään jäänyt huomiotta – Move-ekosysteemiin.

1. Siirrä

Move-ohjelmointikieli luotiin alun perin Metan hylättyä Diem-projektia (alun perin nimeltään Libra) varten, jonka tavoitteena oli kehittää vakaampi ja säännellympi stablecoin metaversaalin vision perustaksi.

Hanke kohtasi kuitenkin voimakasta vastustusta ja maailmanlaajuisten sääntelyviranomaisten jatkuvaa painostusta. Ne pelkäsivät, että Diemin laajuus ja Facebookin laaja käyttäjäkunta voisivat uhata rahoitusvakautta, rahapolitiikkaa ja tietosuojaa. Bidenin hallinnon johtava painostus pakotti lopulta Metan luopumaan Diem-hankkeesta.

Onneksi Diemin ydintä ei hylätty. Alkuperäisestä tiimistä irrottautuneet eri ryhmät jatkoivat Moven tutkimista ja kehittämistä, ja siitä kehittyivät nykyisin tuntemamme Move-kaksoset, Sui ja Aptos. Lisäksi muut hankkeet, kuten Linera (Rust-pohjainen lohkoketju, joka on saanut vaikutteita Movesta) ja hiljattain julkistettu Movement, ovat vielä lapsenkengissä.

Miksi lopetetun hankkeen jäännösvaikutukset ovat olleet niin merkittäviä? Move on johtavan Web2-yrityksen kehittämä lohkoketjuohjelmointikieli, jolla on vankka perusta. Sen suunnittelussa keskityttiin ratkaisemaan suorituskyky- ja tietoturvaongelmia, joita esiintyy nykyisissä lohkoketjukielissä, erityisesti Solidityssä. Sen suunnittelutavoitteina oli luoda omaisuudenhallintaan ja pääsynvalvontaan räätälöity tyyppijärjestelmä. Tiivistän keskeiset kohdat seuraavasti:

• Turvallisuus: Moven suunnittelussa tietoturva on etusijalla, ja siinä käytetään staattisia tyyppitarkistuksia ja resurssien hallintaa estämään yleisiä haavoittuvuuksia, kuten ylivuotovirheitä ja uudelleenkytkentähyökkäyksiä. Verrattuna muihin kielten virtuaalikoneisiin Move tukee erilaisia tietoturvaominaisuuksia, kuten alla oleva Nansenin vertailu osoittaa.
  
• Kokoonpantavuus: Move tukee modulaarisuutta ja kokoonpantavuutta, jolloin kehittäjät voivat helposti luoda ja yhdistää erilaisia älykkäitä sopimuksia monimutkaisempien sovellusten rakentamiseksi.
• Suorituskyky: Moven virtuaalikone on optimoitu (tukee rinnakkaiskäsittelyä, muistinhallintaa ja kääntäjän optimointeja) älykkäiden sopimusten tehokkaaseen suorittamiseen, mikä parantaa transaktioiden nopeutta ja läpimenoa.

Modulaaristen EVM-ketjujen kyllästämillä markkinoilla Move edustaa rohkeaa yritystä johonkin erilaiseen. Olet ehkä törmännyt samanlaisiin väitteisiin monien julkisten ketjujen esittelyissä, mutta suosittelen kokemaan sen omakohtaisesti, jotta ymmärtäisit nämä käsitteet todella.

2. Sui

2.1 Arkkitehtuuri

Yhtenä Move-kaksosista Sui joutui jo varhaisessa vaiheessa kritiikin kohteeksi, koska hänellä oli ongelmia, jotka liittyivät ilmaan pudottamiseen ja kuponkien vapautusmekanismeihin. Kun nämä ongelmat kuitenkin jätetään syrjään ja keskitytään vain itse projektiin, Sui on osoittanut erinomaisuutta sekä suorituskyvyssä että käyttäjäkokemuksessa, erityisesti pelialalla.

Menestys on tiiviisti sidoksissa sen arkkitehtuuriin, jota on parannettu erityisesti valtavirran käyttöönoton kannalta. Seuraavassa on lyhyt katsaus Suin arkkitehtuuriin liittyviin innovaatioihin:

1. Objektitallennusmalli: Tämä komponentti on Suin Moveen tekemien parannusten ydin. Objektitallennusmalli tallentaa tiedot yksittäisinä objekteina, joilla kullakin on yksilöllinen tunniste. Toisin kuin perinteisissä tietokantajärjestelmissä, objektitallennusmallissa ei ole kiinteää tietorakennetta, ja siinä voidaan tallentaa erilaisia tietotyyppejä, kuten tekstiä, kuvia, videoita ja ääntä. Tämä malli mahdollistaa rinnakkaisen suorituksen ja horisontaalisen skaalautumisen (solmujen lisääminen tallennuskapasiteetin laajentamiseksi). Suin suunnittelu pyörii tämän mallin ympärillä.
2. Syy-yhteysjärjestys: Varmistaa, että tapahtumat suoritetaan järjestyksessä, joka kunnioittaa syy-yhteyksiä, jolloin vältetään tietoristiriidat ja epäjohdonmukaisuudet. Tämän ansiosta Sui voi käsitellä suuria määriä samanaikaisia tapahtumia säilyttäen samalla tietojen yhdenmukaisuuden.
3. Narwhal- ja Bullshark- konsensuskoneet: Sui käyttää konsensusmoottoreina Narwhalia ja Bullsharkia. Narwhal vastaa transaktioiden järjestämisestä ja validoinnista ylläpitämällä paikallista transaktiopoolia, lajittelemalla transaktiot syy-yhteyksien perusteella ja lähettämällä ne. Bullshark, joka vastaanottaa lajitellun tapahtumaluettelon Narwhalilta, äänestää luettelosta Byzantine Fault Tolerance (BFT) -konsensuksen avulla varmistaakseen, että kaikki solmut ovat yhtä mieltä tapahtumien järjestyksestä.
4. Sui Move: Sui laajentaa Move-kieltä lisäämällä uusia ominaisuuksia, kuten tuen NFT:ille, omaisuudenhallinnalle ja tietojen tallennukselle.
5. Sui Framework: Sui tarjoaa täydellisen kehyksen, jonka avulla kehittäjät voivat rakentaa ja ottaa sovelluksia käyttöön nopeasti, mukaan lukien työkalut ja kirjastot, kuten Sui Wallet, Sui SDK ja Sui CLI.

Suin arkkitehtuurin ansiosta se pystyy käsittelemään suuria määriä samanaikaisia transaktioita säilyttäen samalla korkean nopeuden, alhaiset maksut ja turvallisuuden. Move-kieli ja Sui-kehys tarjoavat kehittäjille myös tehokkaita työkaluja turvallisten, skaalautuvien ja käyttäjäystävällisten sovellusten rakentamiseen.

2.2 Konsensus

Sui-lohkoketju käyttää Mysticeti-nimistä konsensusmekanismia, joka on BFT (Byzantine Fault Tolerant) -konsensus, joka on suunniteltu alhaisen viiveen ja korkean läpimenon varmistamiseksi.

Mysticeti antaa useiden validoijien ehdottaa lohkoja rinnakkain, jolloin verkon kaistanleveys hyödynnetään täysimääräisesti ja sensuuria voidaan torjua. Lisäksi protokolla vaatii vain kolme viestikierrosta lohkon viimeistelemiseksi suunnatusta asyklisestä graafista (DAG), mikä vastaa teoreettista minimiä aivan kuten pBFT:ssä.

Toimitussäännöt mahdollistavat rinnakkaisen äänestyksen ja lohkojohtajan sertifioinnin, mikä vähentää mediaani- ja loppuviiveaikaa entisestään. Toimitussäännöt sallivat myös sen, että lohkojohtajat eivät ole käytettävissä ilman, että viive kasvaa merkittävästi.

Mysticeti oli toiminut testiverkossa kolme kuukautta ennen Suin pääverkon käynnistämistä, ja sen tulokset olivat merkittäviä, kuten 80 prosentin vähennys latenssissa. Nyt Suin verkko pystyy käsittelemään kymmeniä tuhansia transaktioita sekunnissa, ja päästä päähän -viive on selvästi alle yhden sekunnin.

Suin lohkoketjussa käytetään myös erityyppistä PoS-konsensusta (Proof-of-Stake), jota kutsutaan nimellä DPoS (Delegated Proof-of-Stake). Kun tapahtuu transaktio, johon liittyy jaettuja objekteja (ns. monimutkaisia transaktioita), Sui käyttää edellä mainittuja Narwhal- ja Bullshark-konsensusmoottoreita transaktioiden järjestämiseen. Verrattuna muihin BFT-konsensusmekanismeihin Suin edut ja haitat voidaan tiivistää kuuteen kohtaan:

Edut:

1. Alhainen viive ja suuri läpäisykyky: Mysticeti-protokolla vähentää merkittävästi konsensuksen viiveaikaa ja lisää verkon läpimenoa rinnakkaisten lohkoehdotusten ja optimoidun viestivirran avulla, minkä ansiosta Sui pystyy käsittelemään kymmeniä tuhansia transaktioita sekunnissa, kun päästä päähän -viiveaika on selvästi alle yhden sekunnin.
2. Sensuurin vastarinta: Mysticeti-protokolla mahdollistaa sen, että useat validoijat voivat ehdottaa lohkoja rinnakkain, mikä parantaa verkon vastustuskykyä sensuuria vastaan.
3. Johtajan epäonnistumisen sietokyky: Toimitussäännöt sietävät johtajien poissaoloa ilman, että viive kasvaa merkittävästi, ja valitsevat automaattisesti uuden johtajan, joka ottaa vastuun, kun johtava solmu epäonnistuu.

Haitat:

1. Monimutkaisuus: Mysticeti-protokollan rakenne on suhteellisen monimutkainen, ja sen toimintamekanismien täydellinen ymmärtäminen edellyttää syvempää teknistä ymmärrystä.
2. Turvallisuus: Vaikka Mysticeti-protokolla suoriutui testiverkossa hyvin, sen turvallisuus on vielä validoitava todellisissa sovelluksissa.
3. Skaalautuvuus: Mysticeti-protokollan skaalautuvuutta on tarkkailtava edelleen, jotta voidaan varmistaa, että se pystyy mukautumaan verkon koon ja transaktiomäärän kasvuun tulevaisuudessa.

2.3 Abstraktit tilit

Suin abstrakti tilimalli (Account Abstraction) on mekanismi, jonka avulla käyttäjät voivat hallinnoida tilejään ja transaktioitaan yksinkertaisemmin ja turvallisemmin abstrahoimalla tili- ja transaktiologiikan taustalla olevasta lohkoketjuprotokollasta, jolloin saavutetaan korkeampi tilien hallinnan ja transaktioiden käsittelyn taso.

Suin abstraktissa tilimallissa tilit eivät ole enää pelkkiä julkisen ja yksityisen avaimen pareja, vaan objekteja, joilla on monipuolisempia ominaisuuksia ja käyttäytymistä. Jokaisella tilillä on yksilöllinen tunniste, jota kutsutaan tilitunnukseksi ja joka liittyy tilin julkiseen ja yksityiseen avainpariin.

Suin abstrakti tilimalli sisältää seuraavat keskeiset osat:

• Tilin kohde: Suin kirjanpidon perusyksikkö. Jokaisella tiliobjektilla on yksilöllinen tilitunnus, ja se sisältää tilin attribuutit ja käyttäytymistavat.
• Tilitiedot: Tiliobjektin ydinosa, joka sisältää tilin perustiedot, kuten tilin tunnuksen ja julkisen ja yksityisen avaimen parin.
• Transaktiokonteksti: Suissa tapahtumien perusyksikkö, joka sisältää tapahtumaan liittyviä tietoja, kuten tapahtuman tunnisteen, tilin tunnisteen ja tapahtumatiedot.
• Tililogiikka: Tilien käyttäytymismallien ja sääntöjen kokoelma Suissa, jossa määritellään, miten tilit käsittelevät tapahtumia ja hallitsevat tilaansa.

Suin abstraktissa tilimallissa tapahtumien käsittelyprosessi sisältää seuraavat vaiheet:

1. Tapahtuman luominen: Käyttäjät luovat tapahtuman ja lähettävät sen Sui-verkkoon.
2. Tapahtuman validointi: Sui-verkko validoi tapahtuman oikeellisuuden ja eheyden.
3. Tilin haku: Sui-verkko etsii vastaavan tiliobjektin tapahtuman tilitunnuksen perusteella.
4. Tililogiikan toteuttaminen: Sui-verkko suorittaa tililogiikan tapahtuman käsittelemiseksi ja tilin tilan päivittämiseksi.
5. Tapahtuman vahvistus: Sui-verkko vahvistaa transaktion tuloksen ja kirjoittaa sen lohkoketjuun.

Yksinkertaisesti sanottuna Suin abstrakti tilimalli on innovatiivinen mekanismi, joka yksinkertaistaa tilien hallintaa ja tapahtumien käsittelyä ja tekee sovelluksista entistä sovelluksenomaisempia.

2.4 Pelaaminen

Jotta lohkoketju voisi erottua edukseen, sen on ensin luotava vankka perusta. Viittasin aiemmin Move-ekosysteemiin rohkeana kokeiluna kahdesta syystä.

Ensinnäkin aikakaudella, jolloin modulaarisuuden käsite on yleistymässä, natiivit Move-ekosysteemit (erityisesti Move-kaksoset) edustavat viimeistä yritystä Layer 1 -ratkaisuihin, mikä on vastoin nykyistä suuntausta.

Useiden heterogeenisten ketjujen viimeaikainen nousu saattaa kuitenkin osoittaa, että modulaarisuus ei ole ainoa ratkaisu.

Toiseksi lohkoketjun rakentaminen uudella ohjelmointikielellä on kuin yrittäisi luoda uuden käyttöjärjestelmän, jolla haastettaisiin iOS ja Android nykypäivän älypuhelinmarkkinoilla – tämä tie on väistämättä täynnä haasteita.

Se, loistaako Move-ekosysteemi tulevina vuosina Solanan tavoin, riippuu merkittävästi siitä, minkä suunnan se valitsee. Suin vastaus tähän haasteeseen on pelaaminen.

Pelaaminen on yksi Web3:n tärkeimmistä portista, mutta useimmat lohkoketjut eivät kuitenkaan tue pelaamista hyvin. Tämä johtuu siitä, että lohkoketjuteknologia on alun perin suunniteltu rahoitussovelluksia varten, ja sen hajautettu arkkitehtuuri on luonnostaan suorituskyvyltään heikompi, joten se soveltuu huonosti pelaamiseen.

Sui on kuitenkin erilainen. Sen malli soveltuu hyvin sekä DeFi-sovelluksiin että muihin kuin rahoitussovelluksiin, kuten peleihin. Kuten aiemmin mainittiin, Suissa kaikki on objekteja. Suissa objektit voivat omistaa muita objekteja, mikä mahdollistaa peleille tai sovelluksille tyypillisten monimutkaisten omaisuushierarkioiden mallintamisen.

Kuvittele, että pelaat peliä, jossa sankarihahmolla on inventaario, jossa on hahmolle kuuluvaa digitaalista omaisuutta. Sui pystyy mallintamaan näitä datahierarkioita tavoilla, joihin muut lohkoketjut eivät pysty. Tämä antaa kehittäjille mahdollisuuden rakentaa sovelluksia ilman, että heidän tarvitsee kiertää ketjun luontaisia rajoituksia.

Lisäksi Sui tekee aktiivisesti yhteistyötä perinteisten Web2-jättien kanssa. Viime vuonna Sui solmi kumppanuussuhteita kolmen eteläkorealaisen pelijätin kanssa neljästä suuresta (Netmarble, NHN ja NCSoft). Tänä vuonna Sui teki yhteistyötä TikTokin kanssa lohkoketjupelien ja SocialFi-hankkeiden kehittämiseksi, mikä tuo perinteisiä jättiläisiä Web3-tilaan.

3. Aptos

Aptos, toinen Move-kieleen perustuva Layer 1 -lohkoketju, on myös sitoutunut rakentamaan suorituskykyisen ja skaalautuvan Web3-infrastruktuurin. Sen arkkitehtuurisuunnittelussa on paljon yhtäläisyyksiä Suin kanssa, mutta siinä on myös joitakin ainutlaatuisia ominaisuuksia.

3.1 Arkkitehtuuri

1. Modulaarinen rakenne: Aptos käyttää modulaarista arkkitehtuuria, jonka ansiosta kehittäjät voivat kehittää ja päivittää eri moduuleja itsenäisesti, mikä parantaa kehitysnopeutta ja joustavuutta.
2. Rinnakkaistoteutusmoottori (Block-STM): Toisin kuin muut lohkoketjut, jotka edellyttävät ennalta ilmoitettuja tietoriippuvuuksia, Aptosin rinnakkaissuoritusmoottori voi käsitellä transaktioita rinnakkain ilman ennakkotietoa tietojen sijainnista, mikä lisää läpimenoa ja vähentää viiveaikaa.
3. Pipelined Transaction Processing: Aptos jakaa tapahtumien käsittelyn useisiin vaiheisiin, kuten etenemiseen, metatietojen järjestämiseen ja erän varastointiin, ja suorittaa nämä vaiheet rinnakkain putkituksen avulla maksimoidakseen läpäisykyvyn ja minimoidakseen viiveen.
4. Move-ohjelmointikieli: Aptos käyttää Move-ohjelmointikieltä, ja se keskittyy Suihin verrattuna pikemminkin hienosäätöön kuin innovointiin. Se esimerkiksi standardoi kieltä, ottaa käyttöön vankemman funktiotuen ja parantaa räätälöintimahdollisuuksia.
5. Joustava tilasynkronointi: Sallii solmujen valita erilaisia tilojen synkronointistrategioita, kuten koko historian tai vain viimeisimmän tilan synkronointi, mikä parantaa solmujen joustavuutta.
6. AptosBFT konsensusmekanismi: AptosBFT on Aptosin käyttämä Byzantine Fault Tolerance -konsensusmekanismi. Se optimoi validoijien välisen viestinnän ja synkronoinnin läpimenon parantamiseksi ja viiveen vähentämiseksi. Verrattuna Suiin, jota voidaan pitää parannettuna versiona DiemBFT:stä, AptosBFT on tehnyt tiettyjä edistysaskeleita tehokkuudessa ja kaatumisen palautuksessa, joten se mainitaan tässä lyhyesti.

Aptosin arkkitehtuurin ansiosta se pystyy käsittelemään suuren määrän samanaikaisia tapahtumia säilyttäen samalla korkean nopeuden, alhaiset maksut ja turvallisuuden. Lisäksi Move-kieli ja Aptos-kehys tarjoavat kehittäjille tehokkaat työkalut turvallisten, skaalautuvien ja käyttäjäystävällisten sovellusten rakentamiseen.

3.2 Lohko-STM

Tutustutaanpa syvällisemmin Aptosin keskeiseen innovaatioon, rinnakkaissuoritusmoottoriin Block-STM:

Block-STM:n keskeiset periaatteet:

1. Ennalta määritetty peräkkäinen suoritus: Lohko-STM perustuu lohkon sisällä tapahtuvien transaktioiden ennalta määriteltyyn järjestykseen. Kaikki transaktiot on suoritettava tässä järjestyksessä lopullisen tilan yhdenmukaisuuden varmistamiseksi.
2. Optimistinen samanaikaisuuden hallinta: Block-STM suorittaa transaktiot optimistisesti rinnakkain olettaen, että ristiriitoja ei synny. Tämä valvontamenetelmä perustuu oletukseen, että ristiriitoja esiintyy harvoin, jolloin transaktiot voivat käyttää ja muokata tietoja ilman lukitusta. Siinä oletetaan, että samanaikaisten konfliktien todennäköisyys on vähäinen, joten muutoksia voidaan jatkaa ja konfliktit tarkistetaan ennen lopullista sitoutumista.
3. Moniversioinen tietorakenne: Optimistisen samanaikaisuuden hallinnan tukemiseksi Block-STM käyttää tietojen tallentamiseen moniversioista tietorakennetta. Jokainen kirjoitusoperaatio luo uuden dataversion, kun taas lukutoiminnot käyttävät vastaavaa dataversiota.
4. Validointi ja uusintayritykset: Kun lohko-STM on suorittanut tapahtuman, se tarkistaa, ovatko sen lukemien tietojen versiot edelleen voimassa. Jos validointi epäonnistuu, mikä viittaa ristiriitaan, tapahtuma merkitään mitättömäksi ja suoritetaan uudelleen.
5. Yhteistoiminnallinen aikataulutus: Block-STM käyttää yhteistoiminnallista aikatauluttajaa koordinoimaan eri säikeiden suoritusta ja validointitehtäviä maksimoiden rinnakkaisuuden.

Block-STM-työnkulku:

1. Tapahtumien ryhmittely: Ryhmittele transaktiot lohkon sisällä ja määritä ne eri säikeille rinnakkaista suoritusta varten.
2. Optimistinen toteutus: Kukin säie suorittaa optimistisesti sille osoitetut transaktiot ja tallentaa kunkin transaktion luku- ja kirjoitussarjan.
3. Validointi: Kun säie on suorittanut transaktion loppuun, se tarkistaa, ovatko sen lukusarjassa olevat tietoversiot edelleen voimassa.
4. Yritä uudelleen: Jos validointi epäonnistuu, mikä viittaa ristiriitaan, tapahtuma merkitään mitättömäksi ja suoritetaan uudelleen.
5. Sitoudu: Kun kaikki transaktiot ovat läpäisseet validoinnin, niiden tulokset kirjoitetaan lohkoketjun tilaan, jolloin transaktio on valmis.

Block-STM:n edut:

1. Suuri läpimeno: Optimistisen samanaikaisuuden hallinnan ja yhteistoiminnallisen aikataulutuksen avulla Block-STM hyödyntää täysimääräisesti moniydinprosessoreita ja saavuttaa suuren läpäisykyvyn.
2. Alhainen viive: Koska transaktioita voidaan suorittaa rinnakkain, Block-STM lyhentää merkittävästi transaktion vahvistusaikaa.
3. Turvallisuus: Block-STM:n ennalta määritellyt peräkkäiset suoritus- ja validointimekanismit varmistavat lopullisen tilan johdonmukaisuuden ja turvallisuuden.

Yhteenvetona voidaan todeta, että Block-STM on tehokas rinnakkainen transaktioiden suoritusmoottori, jossa yhdistyvät optimistinen samanaikaisuuden hallinta, moniversioiset tietorakenteet ja yhteistoiminnallinen aikataulutus lohkoketjujen läpimenon maksimoimiseksi ja samalla turvallisuuden ja oikeellisuuden varmistamiseksi.

3.3 Tilin abstraktio

Toisin kuin Suin suorempi lähestymistapa tilien abstrahointiin, Aptos tukee rajoitetumpaa abstrahointiulottuvuutta, eikä siinä ole erityisiä ennalta määriteltyjä standardeja. Aptosin tilien abstrahointiominaisuudet ilmenevät ensisijaisesti seuraavilla alueilla:

1. Modulaarinen tilinhallinta: Käyttää Move-moduuleja tilien määrittelyyn ja hallintaan, jolloin kehittäjät voivat luoda mukautettuja moduuleja eri tilityyppejä ja toimintoja varten.
2. Joustava avainten hallinta: Antaa käyttäjille mahdollisuuden käyttää eri avaimia eri tilitoimintoihin, esimerkiksi käyttää yhtä avainta tapahtumien allekirjoittamiseen ja toista tilinhallintaan.
3. Ohjelmoitava tapahtuman todentaminen: Kehittäjät voivat määritellä Move-moduuleissa mukautetun tapahtuman varmennuslogiikan, kuten usean allekirjoituksen tai rajoitusten, eri sovelluskohtausten täyttämiseksi.

3.4 Kumppanuus Microsoftin kanssa

Verrattuna Suihin, joka keskittyy enemmän pelien kehittämiseen, Aptosilla ei ole erityistä kehitystavoitetta. Sen iskulause on olla tuotantoon parhaiten soveltuva lohkoketju.

Yksi merkittävä seikka on Aptosin ja Microsoftin välinen yhteistyö, jonka tavoitteena on integroida Microsoftin tekoälyteknologia lohkoketjuun. Heidän ensimmäinen yhteistyötuotteensa, Aptos Assistant, Aptos-verkkoon rakennettu generatiivinen tekoälyavustaja, on jo julkaistu virallisella verkkosivustolla. Lisää tekoälytuotteita julkistetaan tulevina kuukausina.

4. Move-ekosysteemi

Vaikka Sui on viime aikoina menestynyt hyvin, Move-ekosysteemin kypsyminen vaatii vielä aikaa verrattuna EVM-pohjaisiin ketjuihin, Solanaan, Toniin ja muihin heterogeenisiin ketjuihin. Huolimatta siitä, että Sui ja Aptos ovat valokeilassa ja tekevät teknologisia läpimurtoja, Move-ekosysteemin kokonaislaajuus ja aktiivisuus eivät vielä vastaa muiden kehittyneiden ekosysteemien tasoa.

Kehittäjien määrä, sovellustyypit ja käyttäjäkunta tarvitsevat vielä aikaa kasvaakseen. Ulkoisen yhteistyön ja toiminnan osalta sekä Sui että Aptos ovat vahvasti Web2-ajattelutavalla, josta puuttuu osa Web3:n olemuksesta, mikä on pitänyt niiden hankkeet suhteellisen hiljaisina alalla.

Move-ekosysteemin mahdollisuudet huomioon ottaen se on kuitenkin erittäin lupaava. Jotkin kehittäjät ovat jo tunnistaneet Moven tulevan arvon. Kuten esipuheessa mainittiin, on jo olemassa hankkeita, jotka sisällyttävät Movea Ethereumin Layer 2 -ratkaisuihin. Tulevaisuudessa Move-ekosysteemi saattaa loistaa ETH:n Layer 2 -alueella. Tällä hetkellä keskitytään siihen, miten Move-ekosysteemiä voidaan edelleen edistää.