Beosin: EIP-7702 ja seuraavan sukupolven AA-lompakon tietoturva-auditointianalyysi

Account Abstraction (AA) on tärkeä pitkän aikavälin tutkimussuunta Ethereum-ekosysteemissä, jonka tavoitteena on rikkoa ulkoisten tilien (EOA) ja sopimustilien välinen raja, jotta lompakolla on vahvempi ohjelmoitavuus, turvallisuus ja päivitettävyys. EIP-4337 on tällä hetkellä yleisin AA-toteutusratkaisu, ja sitä on käytetty laajalti useissa EntryPoint-pohjaisissa älykkäissä sopimuslompakoissa (kuten Safe, Stacks ja Argent). EIP-4337:llä on kuitenkin edelleen tiettyjä rajoituksia ketjun alkuperäisyyden, toiminnan monimutkaisuuden ja ekologisen yhteensopivuuden suhteen, koska siinä on otettu käyttöön riippumaton transaktiopooli ja ramppisopimusmekanismi.

pääsyn kynnyksen alentamiseksi ja tiliabstraktioiden alkuperäisen tuen parantamiseksi Vitalik ehdotti EIP-7702:ta vuonna 2024 ja sisällytti sen Pectran päivitykseen. EIP-7702:n ydinajatuksena on, että alkuperäinen EOA voi suorittaa tietyn osoitteen sopimuskoodin (contract_code) transaktiota aloitettaessa ja käyttää tätä koodia tapahtuman suorituslogiikan määrittämiseen.

EIP-7702 esittelee uuden mekanismin "tapahtumatason koodin syöttämiseen", jonka avulla käyttäjätilit voivat määrittää dynaamisesti suorituslogiikan kussakin tapahtumassa sen sijaan, että ne luottaisivat ennalta käyttöönotettuun sopimuskoodiin. Tämä rikkoo perinteisen staattisen koodipohjaisen käyttöoikeusmallin, lisää joustavuutta ja tuo mukanaan uusia tietoturvahaasteita: harkintalogiikkaan perustuvat sopimukset, kuten isContract ja extcodehash, voivat mitätöidä, ja jotkin järjestelmät, jotka olettavat, että kutsuja on puhdas EOA, voidaan myös ohittaa. Auditoijille on tärkeää paitsi todentaa itse syötetyn koodin turvallisuus myös arvioida sen mahdollinen vaikutus muihin sopimusjärjestelmiin dynaamisessa kontekstissa.

Tässä artikkelissa Beosinin tietoturvatiimi keskittyy EIP-7702:n suunnitteluperiaatteisiin ja keskeisiin ominaisuuksiin, selvittää järjestelmällisesti turvallisuusriskejä, joita sen pohjalta rakennettu AA-lompakko voi kohdata auditoinnissa, ja esittää auditointiprosessia ja käytännön ehdotuksia, jotka auttavat tietoturvatutkijoita selviytymään paremmin tämän uuden paradigman teknisistä haasteista.

1. Johdanto EIP-77021:een

. EIP-7702 Tekninen

yleiskatsausEIP-7702 esittelee uuden tapahtumatyypin, 0x 04 (SetCode), jonka avulla EOA voi valtuuttaa sopimuskoodin, joka on suoritettava tämän tapahtuman kautta, seuraavalla tapahtumarakenteella:

1. rlp([chain_id, nonce, max_priority_fee_per_gas, max_ fee_per_gas, gas_limit,

2. kohde, arvo, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Jos authorization_list sisältää useita valtuutusluetteloita ja voi sisältää myös muiden kuin tapahtuman aloittajien valtuutustoimintoja, sisäinen rakenne on:

1. authorization_list = [[chain_id, osoite, nonce, y_parity, r, s]].

jossa chain_id edustaa ketjua, jossa käyttäjän valtuutus tulee voimaan, ja sen arvon on oltava yhtä suuri kuin suorittavan ketjun ketjutunnus tai 0. Kun chain_id on 0, valtuutus tulee voimaan kaikissa EVM-ketjuissa, jotka tukevat EIP-7702:ta, mutta vain, jos muut parametrit (kuten nonce) vastaavat toisiaan. Osoite ilmaisee käyttäjän valtuuttaman kohdesopimusosoitteen.

Kun valtuutus on valmis, järjestelmä muuttaa valtuutetun käyttäjän koodikentän muotoon 0x ef 0100 || osoite, jossa osoite on valtuutettu sopimusosoite. Jos haluat poistaa valtuutuksen, aloita SetCode-tapahtuma, jonka osoitteeksi on asetettu 0.

pikriinihappo. EIP 7702:n edut

(1) Joustavuus ja räätälöinti

Abstraktit tilitKirjoittamalla tililogiikkaa älykkäisiin sopimuksiin voit mukauttaa toimintoja joustavasti tarpeidesi mukaan. Käyttäjät voivat esimerkiksi määrittää usean allekirjoituksen, sosiaalisen palautuksen ja kiintiön hallinnan vastaamaan yksilöiden tai yritysten tarpeita eri skenaarioissa. Tämä rakenne parantaa huomattavasti tilin toiminnallista skaalautuvuutta ja murtaa perinteisten ulkoisten tilien (EOA) rajoitukset.

(2) Parannettu

turvallisuusAbstraktit tilit tarjoavat monikerroksisen turvamekanismin, mukaan lukien monivaiheinen todennus, tapahtumarajat ja sosiaalinen palautus. Vaikka käyttäjä menettäisi yksityisen avaimensa, hän voi palauttaa tilinsä luotettujen yhteystietojen tai monivaiheisen todennuksen avulla, jolloin vältytään pysyvältä omaisuuden menetykseltä, joka johtuu yksityisen avaimen katoamisesta perinteisillä tileillä. Samalla toiminnot, kuten rajavalvonta, voivat myös estää suurten rahamäärien varastamisen pahantahtoisesti.

(3) Gas Optimized

Abstraction Account tukee joustavaa kaasunottomekanismia, jonka avulla käyttäjät voivat maksaa kaasusta kolmannen osapuolen kautta ja jopa käyttää suoraan muita tokeneita transaktiomaksujen maksamiseen. Tämä mekanismi ei ainoastaan vähennä käyttäjien käyttökustannuksia, vaan myös yksinkertaistaa entisestään lohkoketjun käyttöä, mikä sopii erityisesti aloitteleville käyttäjille tai monimutkaisille monivaiheisille transaktioskenaarioille.

(4) Edistä Web3:n popularisointiaOptimoimalla

kokemusta ja turvallisuutta abstraktit tilit piilottavat lohkoketjun monimutkaisuuden paikkoihin, joita käyttäjät eivät näe, ja tarjoavat käteviä toimintoja lähempänä Web2:ta. Tämä muotoilu vähentää tavallisten käyttäjien oppimiskustannuksia, antaa useammille ihmisille mahdollisuuden osallistua Web3-sovelluksiin ilman esteitä ja edistää hajautetun teknologian popularisointia.

2. EIP-7702:n tietoturvariskien analyysi käytännössä

Vaikka EIP-7702 on tuonut uutta vauhtia Ethereum-ekosysteemiin ja laajentanut runsaasti sovellusskenaarioita, se on samalla väistämättä tuonut mukanaan uusia tietoturvariskejä:

1. Valtuutuksen uusintahyökkäys

EIP-7702-mallissa, jos käyttäjä valtuuttaa chain_ Jos id-kentän arvoksi on määritetty 0, valtuutus voi tulla voimaan useissa ketjuissa. Vaikka tämä "ketjujen välisen yleisen valtuutuksen" rakenne parantaa joustavuutta joissakin skenaarioissa, se aiheuttaa myös ilmeisiä tietoturvariskejä.

On tärkeää huomata, että vaikka saman osoitteen tili-identiteetti olisi sama eri ketjuissa, sen takana oleva sopimuksen toteutus voi olla täysin erilainen. Tämä tarkoittaa, että hyökkääjä voi ottaa käyttöön sopimuksen haitallisen version toisessa ketjussa ja suorittaa tahattomia toimia käyttämällä saman osoitteen valtuutusta ketjussa, mikä aiheuttaa riskejä käyttäjän omaisuudelle.

Siksi lompakkopalveluntarjoajien tai käyttöliittymän vuorovaikutusalustojen on tällaisia valtuutustoimintoja suorittaessaan tarkistettava selvästi, onko käyttäjän valtuutuksessa ilmoitettu chainId yhdenmukainen nykyisen yhteysverkon kanssa. Jos käyttäjän havaitaan asettavan chainId-arvoksi 0, käyttäjää on annettava selkeä riskivaroitus muistuttamaan siitä, että valtuutus tulee voimaan kaikissa EVM-yhteensopivissa ketjuissa ja että pahantahtoiset sopimukset voivat käyttää sitä väärin.

Lisäksi palveluntarjoajan tulee myös arvioida, rajoitetaanko tai kielletäänkö valtuutus chainId 0:lla oletusarvoisesti käyttöliittymäkerroksessa virheellisen toiminnan tai tietojenkalasteluhyökkäysten riskin vähentämiseksi.

2. Sopimuksen yhteensopivuus

1) Sopimuksen takaisinsoiton yhteensopivuus

rahaa siirretään olemassa olevien token-sopimusten, kuten ERC-721, ERC-777 ja ERC 1155, sopimusosoitteeseen, he kutsuvat vakiotakaisinsoittorajapintoja (kuten onERC 721 Received, tokensReceived) siirtotoiminnon suorittamiseksi loppuun. Jos vastaanottava osoite ei toteuta vastaavaa liitäntää, siirto epäonnistuu tai jopa aiheuttaa omaisuuden lukittumisen.

EIP-7702:ssa käyttäjän osoite voidaan muuttaa sopimustiliksi antamalla sopimuskoodi "set_code"-toiminnon kautta. Tässä tapauksessa:

• Käyttäjän osoitetta pidetään sopimuksena;

• Jos sopimuksessa ei toteuteta tarvittavaa takaisinsoittorajapintaa, tunnuksen siirto epäonnistuu;

• Käyttäjät eivät välttämättä pysty vastaanottamaan valtavirran tokeneita tietämättään.

Siksi kehittäjien olisi varmistettava, että käyttäjän delegoima kohdesopimus toteuttaa asiaankuuluvan takaisinsoittorajapinnan, jotta varmistetaan yhteensopivuus valtavirran tokenien kanssa.

(2) "tx.origin"-vahvistus epäonnistuuPerinteisissä

sopimuksissa "tx.origin"-koodia käytetään usein määrittämään, onko tapahtuma suoraan käyttäjän käynnistämä, ja sitä käytetään estämään turvatarkastukset, kuten sopimuskutsut.

EIP-7702-skenaariossa

• käyttäjä kuitenkin allekirjoittaa valtuutustapahtuman, ja uudelleenlayerointi tai niputtaja lähettää sen käyttäjän puolesta. Kun transaktio suoritetaan, "tx.origin" on uudelleenkerroksen osoite, ei käyttäjän osoite.

• "msg.sender" on lompakkosopimus, joka edustaa käyttäjän henkilöllisyyttä.

Siksi "tx.origin == msg.sender" -periaatteeseen perustuva lupavahvistus aiheuttaa laillisten käyttäjätoimintojen hylkäämisen ja luotettavuuden menettämisen, ja samat rajoitetut sopimuskutsut, kuten "tx.origin == user", mitätöidään. On suositeltavaa luopua "tx.origin" turvallisuusarvioinnin perustana ja käyttää sen sijaan allekirjoituksen vahvistus- tai valtuutusmekanismia.

(3) "isContract" arvioi väärinMonet

sopimukset estävät sopimustilejä osallistumasta tiettyihin toimintoihin, kuten airdropeihin, flash-myyntiin jne., "isContract(address)":

require(!isContract(msg.sender), "Contracts not allowed"

). EIP-7702-mekanismissa käyttäjän osoite voidaan muuttaa sopimustiliksi "set_code"-tapahtumalla, ja "isContract" palauttaa tosi, ja sopimus tunnistaa virheellisesti laillisen käyttäjän sopimustiliksi ja kieltäytyy osallistumasta toimintoon, mikä johtaa siihen, että käyttäjä ei voi käyttää tiettyjä palveluita ja kokemus estetään.

Sopimuslompakoiden asteittaisen yleistymisen myötä "isContractiin" luotetaan sen määrittämiseksi, onko "ihmiskäyttäjä" enää turvallinen, ja on suositeltavaa käyttää tarkempia käyttäjän tunnistusmenetelmiä, kuten allekirjoituksen todentamista.

3. TietojenkalasteluhyökkäysEIP-7702

:n delegointimekanismin käyttöönoton jälkeen delegoitu älysopimus hallitsee täysin käyttäjän tilillä olevia varoja. Kun käyttäjä valtuuttaa haitallisen sopimuksen, hyökkääjä voi saada täyden hallinnan tilin varoihin, mikä johtaa varojen nopeaan siirtoon tai varkauteen, mikä on erittäin riskialtista.

Sen vuoksi lompakkopalvelujen tarjoajien on tuettava EIP-7702-transaktioiden ratkaisu- ja riskien tunnistamismekanismia mahdollisimman pianRatkaiseva. Kun käyttäjä allekirjoittaa valtuutustapahtuman, käyttöliittymän tulee näyttää selkeästi ja näkyvästi kohdesopimuksen osoite ja yhdistää tukitiedot, kuten sopimuksen lähde- ja käyttöönottotiedot, auttaakseen käyttäjiä tunnistamaan mahdollisen tietojenkalastelun tai vilpillisen toiminnan, mikä vähentää virheellisen allekirjoittamisen riskiä. Lisäksi lompakkopalvelun tulisi integroida kohdesopimuksen automaattiset tietoturva-analyysiominaisuudet, kuten sopimuskoodin avoimen lähdekoodin tilan tarkistus, lupamallin analyysi ja mahdollisesti vaarallisten toimintojen tunnistaminen, jotta käyttäjät voivat tehdä turvallisempia päätöksiä ennen valtuutusta.

EIP-7702:ssa otetaan käyttöön delegoitu allekirjoitusmuoto, joka ei ole yhteensopiva nykyisten EIP-191- ja EIP-712-allekirjoitusstandardien kanssa. Sen allekirjoitus voi helposti ohittaa lompakon alkuperäisen allekirjoitusvaroituksen ja vuorovaikutuskehotteen, mikä lisää entisestään riskiä, että käyttäjiä huijataan allekirjoittamaan haitallisia toimintoja. Siksi allekirjoitusrakenteen tunnistus- ja käsittelymekanismin käyttöönotto lompakon toteutuksessa on keskeinen linkki käyttäjien turvallisuuden varmistamiseksi.

4. Lompakon sopimusriskit

(1) Lompakon sopimusviranomaisen hallinta

Monet EIP-7702-lompakkosopimukset käyttävät välityspalvelinarkkitehtuuria (tai sisäänrakennettuja hallintaoikeuksia) loogisten päivitysten tukemiseksi. Tämä aiheuttaa kuitenkin myös suuremman oikeuksien hallinnan riskin. Jos eskalointioikeuksia ei ole tiukasti rajoitettu, hyökkääjä voi korvata toteutussopimuksen ja lisätä haitallista koodia, mikä johtaa käyttäjän tilin peukalointiin tai varojen varastamiseen.

Suojaussuositukset

• : Käytä moniallekirjoitus-, monimenetelmätodennusta- tai aikalukitusmekanismeja eskalointioikeuksien hallintaan.

• Koodin ja käyttöoikeuksien muutokset edellyttävät tiukkaa valvontaa ja tietoturvan vahvistusta.

• Päivitysprosessi on avoin ja läpinäkyvä, jotta varmistetaan käyttäjien oikeus tietää ja osallistua.

(2) Tallennusristiriitojen ja tietojen eristämisen riski,

lompakkosopimusversiot tai eri lompakkopalveluntarjoajat voivat käyttää samaa tallennuspaikkaa uudelleen. Jos käyttäjä vaihtaa lompakkopalveluntarjoajaa tai päivittää lompakon logiikkaa, tallennuspaikan uudelleenkäyttö aiheuttaa tilamuuttujan ristiriidan, tietojen korvaamisen, lukupoikkeuksia ja muita ongelmia. Tämä ei ainoastaan voi häiritä lompakon normaalia toimintaa, vaan se voi myös johtaa varojen menetykseen tai epänormaaleihin käyttöoikeuksiin.

Suojaussuositukset:

• Käytä erityistä tallennustilan eristysmallia, kuten EIP-1967-standardia, tai hyödynnä yksilöllistä nimitilaa tallennuspaikkojen hallintaan.

• Kun päivität sopimusta, varmista, että tallennustilan asettelu on yhteensopiva ja vältä päällekkäisiä muuttujia.

• Testaa tarkasti tallennetun tilan uskottavuus päivitysprosessin aikana.

(3) Nonce-hallinta lompakon sisällä

Lompakkosopimus perustaa yleensä noncen sisälle ja hallitsee itseään varmistaakseen käyttäjän toimintojen suoritusjärjestyksen ja estääkseen toistohyökkäykset. Jos noncea käytetään väärin, käyttäjän toimintoa ei suoriteta oikein.

Turvallisuussuositus:

• Nonce-arvo on tarkistettava väkisin vastaavan arvon (tai lisäyksen) varalta, eikä sitä voi ohittaa.

• Funktiot eivät saa muokata noncea suoraan, ja nonce päivittyy vasta, kun käyttäjän toiminto suoritetaan.

• Suunnittele vikasietoisuus- ja palautusmekanismit nonce-poikkeuksille nonce-umpikujien välttämiseksi.

(4) Toiminnon soittajan lupien tarkistusTurvallisuuden

varmistamiseksi lompakkosopimuksessa on varmistettava, että avaintoiminnon soittaja on lompakon omistajatili. Kaksi yleistä menetelmää ovat:

• ketjun ulkopuolinen allekirjoitus valtuuttaa

käyttäjät allekirjoittamaan joukon toimintoja yksityisen avaimen kautta, ja lompakkosopimus tarkistaa, onko allekirjoitus laillinen, vanhentunut ja täyttääkö se ketjun vastaavan noncen. Tätä menetelmää voidaan soveltaa EIP-7702:n suosittelemaan välitystapahtumatilaan (käyttäjän offline-allekirjoitus + uudelleenkerros lähettää tapahtuman käyttäjän puolesta).

• Kutsurajoitus (msg.sender == address(this))

-käyttäjän toimintafunktion saa laukaista vain itse sopimus, joka on pohjimmiltaan puhelupolun ohjausmekanismi, joka varmistaa, että ulkoisen käynnistäjän on oltava itse tili. Tämä vastaa käytännössä sitä, että soittajan on oltava alkuperäinen EOA, koska sopimusosoite on EOA-osoite.

3. Näkymät: Ehdotus EIP-7702:sta ja tulevasta AA-lompakkostandardista

EIP-7702 ei ole vain perinteisen tilimallin innovaatio, vaan myös merkittävä tilin abstraktioekosysteemin edistäminen. Sen tarjoama mahdollisuus ladata sopimuskoodia tuo laajan tilan tulevaisuuden lompakon suunnittelulle ja sopimusjärjestelmälle ja asettaa myös uusia vaatimuksia tietoturvatarkastusstandardeille.

1. Yhteiskehitys EIP-4337:n kanssa: Kohti kaksimuotoista yhteensopivuuttaVaikka

EIP-7702:lla ja EIP-4337:llä on erilaiset suunnittelutavoitteet, edellinen rekonstruoi tilin koodin latausmekanismin ja jälkimmäinen rakentaa täydellisen tapahtumien syöttö- ja pakkausekosysteemin. Nämä kaksi eivät kuitenkaan ole ristiriidassa, vaan täydentävät toisiaan voimakkaasti:

● EIP-4337 tarjoaa "yhteisen transaktiokanavan" ja "abstraktin tilien toteuttamisrajapinnan";

● EIP-7702:n avulla käyttäjätilit voivat dynaamisesti myöntää sopimuslogiikkaominaisuuksia muuttamatta osoitetta;

Siksi lompakot voivat tulevaisuudessa ottaa käyttöön "kaksimuotoisen tukiarkkitehtuurin": käyttää EIP-7702:ta kevyenä korvikkeena ketjuissa, jotka eivät tue EIP-4337:ää, ja luottaa edelleen EIP-4337:n koko protokollapinoon skenaarioissa, jotka edellyttävät ketjun ulkopuolista pakkausta ja usean käyttäjän yhdistämistä.

Tämän kaksitilaisen mekanismin avulla lompakot voivat myös tukea joustavampia tilien käyttöoikeusmalleja, downgrade-mekanismeja ja palautusjärjestelmiä ydinkerroksessa.

2. Tuki ja inspiraatio uudelle lompakkologiikalle, kuten MPC ja ZK, ja

EIP-7702:n suosittelemalla tilisopimusmekanismilla on luonnollinen integrointipotentiaali nykyiseen suosittuun MPC-lompakkoon, ZK-lompakkoon, modulaariseen lompakkoon ja muihin uusiin arkkitehtuureihin:

● MPC-mallissa allekirjoituskäyttäytyminen ei enää perustu yhteen yksityiseen avaimeen, vaan se on monen osapuolen yhteistyöhön perustuvaa päätöksentekoa. EIP-7702:n ja MPC:n konvergenssin kautta luodut allekirjoitukset ohjaavat dynaamisesti ladattua sopimuslogiikkaa, mikä mahdollistaa joustavammat toteutusstrategiat.

● ZK-lompakko vahvistaa käyttäjän henkilöllisyyden tai valtuutuksen nollatietotodisteiden avulla paljastamatta yksityisen avaimen tietoja. Yhdessä EIP-7702:n kanssa ZK-lompakot voivat väliaikaisesti syöttää tiettyjä logiikkasopimuksia vahvistuksen päätyttyä, jotta voidaan toteuttaa henkilökohtaista käyttäytymistä yksityisyyden laskennan jälkeen, kuten tietyn logiikan automaattinen suorittaminen vasta, kun tietyt tietosuojaehdot täyttyvät.

● Modulaariset lompakot voivat käyttää EIP-7702:ta tililogiikan purkamiseen useisiin moduuleihin ja niiden dynaamiseen lataamiseen tarvittaessa.

Siksi EIP-7702 tarjoaa alkuperäisemmän "suoritussäiliön" edellä mainituille edistyneille lompakoille: eri sopimuslogiikkaan voidaan syöttää sama käyttäjäosoite, jolloin vältetään osoiteriippuvuusongelma perinteisessä sopimuksen käyttöönottoprosessissa ja eliminoidaan esikäyttöönoton tarve, mikä parantaa huomattavasti tilin käyttäytymisen joustavuutta ja yhdistelmää.

3. Vaikutukset sopimuskehittäjiin ja

perusteellisen muutoksen kehitysparadigmassa. Sopimuskehittäjät eivät enää käsittele soittajaa vain perinteisenä EOA:na tai kiinteänä sopimustilinä, vaan heidän on sopeuduttava uuteen mekanismiin: soittajan henkilöllisyyttä voidaan vaihtaa dynaamisesti EOA:n ja sopimuksen tilan välillä tapahtuman aikana, eikä tilin käyttäytymislogiikkaa enää vahvisteta staattisesti, vaan sitä voidaan muuttaa joustavasti kysynnän mukaan. Tämä edellyttää, että kehittäjät ja tarkastajat:

• ottavat käyttöön tiukemman soittajan todentamisen ja lupien arvioinnin logiikan;

• Tarkista, vaikuttaako dynaaminen sopimuslogiikka puhelupolkuun;

• tunnistaa mahdolliset haavoittuvuudet, jotka perustuvat käyttäytymiseen, kuten msg.sender.code.length == 0, isContract() jne.;

• Selvennetään sopimuslogiikan "kontekstiriippuvuuksia", kuten staattisten kutsujen ja delegointikutsujen rajavalvontaa;

• Työkaluketjutasolla tuetaan setCode-skenaarioiden simulointia ja palautusanalyysiä.

Toisin sanoen koodin suojaus ei ole enää vain "käyttöönottoa edeltävä ongelma", vaan "dynaaminen prosessi, joka on tarkistettava kutsun ja tapahtuman aikana".

4.

esittelee kevyemmän, alkuperäisen ja joustavamman tiliabstraktion (AA) toteutuksen, jotta tavallinen EOA voi sisältää sopimuslogiikan ja suorittaa sen yhdellä tapahtumalla. Tämä mekanismi rikkoo perinteiset staattiset oletukset tilin käyttäytymisestä, eivätkä kehittäjät voi enää luottaa pelkästään tiliosoitteen koodin tilaan arvioidessaan sen käyttäytymismallia, vaan heidän on rekonstruoitava ymmärrys soittajan identiteetistä ja auktoriteettirajoista.

myötä tietoturva-analytiikassa tapahtuu paradigman muutos. Tarkastuksen painopiste ei enää rajoitu siihen, onko osoitteella käyttöoikeudet, vaan siihen, "mitä transaktiossa käytetty sopimuslogiikka voi tehdä nykyisessä kontekstissa". Jokaisella tapahtumalla voi olla itsenäinen käyttäytymisen määritelmä, mikä antaa tilille enemmän toiminnallisuutta ja asettaa korkeampia vaatimuksia tietoturvatarkastuksille.