Wat is een cross-chain bridge exploit en hoe ontstaan deze aanvallen?

Wat is een cross-chain bridge exploit?

Een cross-chain bridge exploit is het misbruiken van een kwetsbaarheid in een bridge: infrastructuur waarmee verschillende blockchains met elkaar kunnen communiceren. Door zo'n kwetsbaarheid kan een aanvaller bijvoorbeeld tokens vrijgeven zonder geldige storting, tokens zonder voldoende onderpand minten of reserves uit de bridge halen.

Een cross-chain bridge maakt het mogelijk om tokens, berichten of andere data tussen afzonderlijke blockchains te verplaatsen. Dat is nodig omdat een blockchain niet automatisch kan controleren wat er op een andere blockchain is gebeurd.

Een exploit kan op verschillende plekken ontstaan. Denk aan een fout in de controle van berichten, te ruime toegangsrechten, een kwetsbaarheid in smart contracts of gestolen private keys van validators of beheerders. Bij sommige bridges bevestigen validators bijvoorbeeld dat een bericht van de ene blockchain echt en geldig is voordat er op de andere blockchain iets gebeurt.

Belangrijk om te weten: een bridge voegt een extra beveiligingslaag toe boven op de blockchains waarmee hij verbinding maakt. Bij sommige bridges vertrouw je bijvoorbeeld op een externe groep validators of een multisig. Andere bridges gebruiken light clients en cryptografische bewijzen, zoals Merkle-bewijzen, om te controleren dat een transactie of gebeurtenis daadwerkelijk op de andere blockchain heeft plaatsgevonden. Het veiligheidsmodel en daarmee de risico's kunnen dus sterk per bridge verschillen.

Een phishingpagina tijdens het bridgen is trouwens niet automatisch een bridge exploit. Zo'n pagina kan je wel naar een kwaadwillend contract sturen of een ongewenste toestemming laten ondertekenen, maar daarmee is de onderliggende bridge zelf nog niet noodzakelijk gekraakt.

Korte samenvatting

• Een cross-chain bridge maakt communicatie en de overdracht van waarde tussen afzonderlijke blockchains mogelijk.
• Een bridge exploit misbruikt een technische of operationele kwetsbaarheid in zo'n bridge.
• Aanvallers kunnen onder meer ongeautoriseerde uitbetalingen veroorzaken of tokens zonder voldoende onderpand minten.
• De verificatie van cross-chain berichten is een belangrijk beveiligingspunt van een bridge.
• Het veiligheidsmodel verschilt per bridge en bepaalt welke extra risico's gebruikers lopen.

Hoe werkt een cross-chain bridge?

Een cross-chain bridge kijkt naar een gebeurtenis op de bronblockchain en voert, nadat die gebeurtenis is gecontroleerd, een bijbehorende actie uit op de doelblockchain.

Stel dat je een token van blockchain A naar blockchain B wilt sturen. Blockchain B kan niet automatisch controleren of jij die token daadwerkelijk op blockchain A hebt verstuurd. Daarom moet de bridge de gebeurtenis op blockchain A waarnemen en verifiëren voordat er iets op blockchain B gebeurt.

Een veelgebruikt model heet lock-and-mint. Je originele tokens worden daarbij vergrendeld op de bronblockchain. Op de doelblockchain wordt vervolgens een wrapped token gemint: een representatie van het originele token. Ga je terug, dan wordt de wrapped token verbrand en kunnen de oorspronkelijke tokens weer worden vrijgegeven.

Voorbeeld: Je vergrendelt 1 token op blockchain A. Na verificatie krijg je op blockchain B 1 wrapped token. Je originele token reist dus niet letterlijk naar blockchain B, maar blijft vergrendeld als onderpand voor de token die je daar ontvangt.

Een andere aanpak werkt met liquiditeitspools. Na een geverifieerde transactie op de bronblockchain kan een pool op de doelblockchain een gelijkwaardige hoeveelheid tokens uitbetalen.

De cruciale stap is steeds de verificatie. De bridge moet bijvoorbeeld controleren of een bericht echt is, van de juiste blockchain komt, aan de juiste voorwaarden voldoet en niet al eerder is verwerkt. Hoe dat gebeurt, verschilt per bridge.

Sommige bridges ondersteunen daarnaast generalised message passing. Ze kunnen dan niet alleen tokens verplaatsen, maar ook andere data of opdrachten tussen blockchains doorgeven en laten uitvoeren. Dat biedt meer mogelijkheden, maar kan ook het aanvalsoppervlak vergroten.

Welke verschillende veiligheidsmodellen gebruiken bridges?

Niet iedere bridge bepaalt op dezelfde manier of een bericht geldig is. Daardoor kan ook het beveiligingsmodel sterk verschillen.

Een bridge kan bijvoorbeeld vertrouwen op:

• Externe validators of multisigs: een groep partijen ondertekent berichten voordat ze op een andere blockchain worden uitgevoerd.
• Light clients: de ene blockchain controleert cryptografische informatie over de toestand van de andere blockchain.
• Cryptografische bewijzen: een bridge gebruikt bijvoorbeeld Merkle-bewijzen of andere cryptografische constructies om gebeurtenissen aan te tonen.
• Optimistische verificatie: berichten worden eerst geaccepteerd, maar krijgen een periode waarin andere partijen een ongeldig bericht kunnen aanvechten.

Deze modellen hebben verschillende afwegingen. Een externe validatorgroep kan bijvoorbeeld eenvoudiger zijn, maar voegt een extra vertrouwenslaag toe. Een bridge die gebeurtenissen cryptografisch controleert, heeft weer andere technische risico's. Daarom zegt alleen het woord 'bridge' nog weinig over hoe veilig het systeem precies is.

Hoe kan een cross-chain bridge worden aangevallen?

Een aanvaller probeert meestal de verificatie van de bridge te omzeilen of de bevoegdheid te krijgen om een ongeldig cross-chain bericht toch goed te keuren.

De gedachte daarachter is simpel: als de doelblockchain ten onrechte gelooft dat er op de bronblockchain tokens zijn gestort of vergrendeld, kan de bridge bijvoorbeeld nieuwe tokens minten of reserves vrijgeven zonder dat daar voldoende onderpand tegenover staat.

Dit kan op meerdere manieren gebeuren:

• Een fout zorgt ervoor dat een onbewezen of vervalst bericht toch wordt geaccepteerd.
• Een aanvaller krijgt voldoende private keys van validators, multisig-ondertekenaars of beheerders in handen.
• Een bug in een smart contract slaat een belangrijke controle over of geeft een account te veel rechten.
• De verificatie van een cryptografisch bewijs, zoals een Merkle-bewijs of light-clientbewijs, bevat een fout.
• Een verkeerde configuratie of upgrade zorgt ervoor dat ongeldige berichten alsnog als geldig worden behandeld.

Een Merkle-bewijs is een compacte cryptografische manier om aan te tonen dat bepaalde data onderdeel is van een grotere dataset, bijvoorbeeld van de gegevens in een blok. Als een bridge zo'n bewijs verkeerd controleert, kan een aanvaller mogelijk een gebeurtenis laten accepteren die nooit geldig heeft plaatsgevonden.

Niet elke aanval loopt dus via gestolen sleutels en niet elke bridge werkt hetzelfde. Om het risico te begrijpen, moet je kijken naar het specifieke verificatie- en beveiligingsmodel van de bridge.

Welke kwetsbaarheden komen vaak voor?

Veel bridge-aanvallen vallen grofweg in een aantal categorieën: fouten in toegangsrechten, fouten in de logica, problemen met berichtverificatie en operationele beveiligingsproblemen.

Permission issues gaan over wie welke handelingen mag uitvoeren. Misschien heeft een beheeraccount te veel rechten, zijn validatoraccounts onvoldoende beveiligd of kunnen bevoegdheden verkeerd worden aangepast. Vooral bij een kleine validator- of multisig-set kan dit een groot risico zijn. Als voldoende ondertekenaars samenwerken of worden gecompromitteerd, kunnen zij ongeldige uitbetalingen autoriseren.

Logic issues zijn fouten in de regels van smart contracts. Een contract verwerkt bijvoorbeeld een bericht zonder alle voorwaarden te controleren of mint en vrijgave zijn verkeerd ingericht. Ook fouten tijdens een upgrade of bij de initialisatie van een contract kunnen hieronder vallen.

Message verification issues ontstaan wanneer een bridge onvoldoende controleert of een cross-chain bericht daadwerkelijk geldig is. Een bridge kan bijvoorbeeld de verkeerde bron accepteren, een cryptografisch bewijs verkeerd controleren of een bericht uitvoeren dat nooit geldig op de bronblockchain is ontstaan.

Key management issues ontstaan wanneer private keys van validators, beheerders of multisig-ondertekenaars worden gestolen of onvoldoende zijn beschermd. De smart contracts kunnen technisch correct werken, terwijl een aanvaller toch geldige handtekeningen kan produceren met gestolen sleutels.

Ook replay attacks zijn een bekend risico. Daarbij wordt een eerder geldig bericht opnieuw gebruikt. Een bridge moet daarom controleren of ieder bericht maar één keer kan worden verwerkt. Een unieke message ID, nonce of hash kan daarbij helpen.

Een audit kan helpen om kwetsbaarheden te vinden, maar is geen garantie dat een bridge foutloos is. Zeker na upgrades, gewijzigde instellingen of veranderingen in off-chain infrastructuur kunnen nieuwe risico's ontstaan.

Hoe spelen frontends en phishing een rol?

Niet ieder verlies tijdens het gebruik van een bridge betekent dat de bridge zelf is geëxploiteerd. Aanvallers kunnen ook proberen gebruikers te misleiden via een vervalste website of interface.

Een nepinterface kan je bijvoorbeeld een transactie naar een verkeerd smart contract laten versturen of toestemming laten geven om tokens uit je wallet te gebruiken. De technische infrastructuur van de bridge kan daarbij volledig intact blijven.

Het onderscheid is belangrijk: bij een bridge exploit wordt een zwakke plek in de bridge of de infrastructuur eromheen misbruikt. Bij phishing wordt meestal de gebruiker misleid om zelf een schadelijke handeling goed te keuren.

Hoe kunnen private keys en smart contracts een rol spelen?

Private keys en smart contracts zijn belangrijke onderdelen van veel bridges. Een probleem in één van beide kan al ernstige gevolgen hebben.

Een private key is een geheime sleutel waarmee transacties of cryptografische handtekeningen kunnen worden gemaakt. Als een bridge bijvoorbeeld pas een uitbetaling uitvoert nadat meerdere validators hebben getekend, ontstaat een groot risico wanneer een aanvaller voldoende van die sleutels weet te bemachtigen. De aanvaller kan dan frauduleuze bridge-opdrachten laten goedkeuren alsof ze legitiem zijn.

Een multisig vereist dat meerdere partijen ondertekenen voordat een actie doorgaat. Dat kan veiliger zijn dan één beheeraccount, maar is niet automatisch veilig. De drempel moet goed gekozen zijn, ondertekenaars moeten voldoende onafhankelijk zijn en private keys moeten goed worden beschermd.

Bij de Ronin Bridge-aanval werden in maart 2022 voldoende validator-keys gecompromitteerd om ongeautoriseerde opnames goed te keuren. Uiteindelijk werden 173.600 ETH en 25,5 miljoen USDC uit de bridge weggehaald. Het bridge-ontwerp werd daarna aangepast en er kwamen aanvullende beveiligingsmaatregelen.

Bij het Harmony Horizon Bridge-incident werden in juni 2022 minstens twee van de vier private keys van bridgevalidators gecompromitteerd. Harmony meldde dat er geen bewijs was dat de bridge-smart contracts of het blockchainprotocol zelf waren aangetast. Het incident laat zien dat een bridge kan worden gekraakt zonder dat er noodzakelijk een fout in het on-chain contract zit.

Smart contracts vormen ondertussen de on-chain regels van veel bridges. Ze controleren bijvoorbeeld handtekeningen of cryptografische bewijzen en voeren vervolgens acties uit, zoals tokens minten, verbranden, vergrendelen of vrijgeven. Als die controles verkeerd zijn ontworpen of geïmplementeerd, kan een aanvaller soms tokens creëren of reserves opnemen zonder geldige onderliggende transactie.

Goede bescherming vereist daarom zowel veilige smart contracts als sterk sleutelbeheer.

Wat zijn de gevolgen van een cross-chain bridge exploit?

Een cross-chain bridge exploit kan ervoor zorgen dat reserves verdwijnen, liquiditeitspools leeglopen of wrapped tokens niet langer volledig gedekt zijn.

Dat laatste kan grote gevolgen hebben. Een wrapped token hoort bij een lock-and-mint-bridge normaal gesproken gedekt te zijn door reserves op een andere blockchain. Als dat onderpand verdwijnt, kan de mogelijkheid om de wrapped token tegen de oorspronkelijke asset in te wisselen onder druk komen te staan. Dat kan ook protocollen raken waarin de token als onderpand, handelsobject of liquiditeit wordt gebruikt.

Projectteams kunnen een bridge soms tijdelijk pauzeren om verdere schade te beperken. Na de Nomad-exploit in augustus 2022 werd bijvoorbeeld verdere verwerking tegengehouden nadat door een fout in de initialisatie ongeldige berichten als geldig konden worden behandeld. Bij het incident werd voor ongeveer 190 miljoen dollar aan assets uit de bridge gehaald.

Bij de exploit van BSC Token Hub in oktober 2022 werd een vervalst cryptografisch bewijs gebruikt waardoor ongeveer 2 miljoen extra BNB konden worden gecreëerd. BNB Chain coördineerde met validators om de blockchain tijdelijk stil te leggen en verdere schade te beperken. Een groot deel van de betrokken BNB bleef daardoor onder controle.

Blockchaintransacties kunnen doorgaans niet simpelweg door een centrale partij worden teruggedraaid zoals bijvoorbeeld een traditionele bankoverschrijving. Toch betekent dat niet dat er nooit kan worden ingegrepen. Afhankelijk van het netwerk kunnen validators, projectteams, tokenuitgevers of governance soms maatregelen nemen om verdere transacties te stoppen, assets te blokkeren of andere herstelmaatregelen uit te voeren.

Een tijdelijke pauze kan verdere schade beperken, maar heeft ook nadelen. Gebruikers kunnen mogelijk tijdelijk niet bridgen of hun tokens niet terughalen. Bovendien betekent een noodstop dat bepaalde beheerders, validators of guardians invloed hebben om delen van het systeem te vertragen of stil te leggen.

Of gebruikers na een exploit worden vergoed, staat niet vast. Dat hangt onder meer af van beschikbare reserves, verzekeringen, besluiten van het project, governance en de vraag of gestolen middelen kunnen worden teruggehaald.

Een grote bridge exploit kan daarnaast het vertrouwen in een project of bridged asset aantasten. Dat kan invloed hebben op liquiditeit en mogelijk ook op de marktprijs, maar het effect verschilt per incident en marktomstandigheden.

Naast het directe financiële verlies kan een bridge daardoor lange tijd minder bruikbaar zijn. Liquiditeit kan afnemen, wrapped tokens kunnen moeilijker inwisselbaar worden en gebruikers kunnen terughoudender worden om de bridge opnieuw te gebruiken.

Welke bekende cross-chain bridge exploits zijn er?

Er zijn meerdere grote bridge exploits geweest. De technische oorzaak verschilde per incident.

• Poly Network: in augustus 2021 werd bij Poly Network voor meer dan 600 miljoen dollar aan crypto verplaatst na het misbruiken van de cross-chain infrastructuur. Een groot deel van de middelen werd later teruggegeven.
• Wormhole: in februari 2022 werd een kwetsbaarheid in Wormhole op Solana misbruikt om wrapped ETH te creëren zonder de vereiste onderliggende dekking. De aanvaller verplaatste vervolgens een deel van de assets naar Ethereum.
• Ronin Bridge: in maart 2022 werden validator-keys gecompromitteerd, waardoor de aanvaller ongeautoriseerde opnames kon goedkeuren. In totaal werden 173.600 ETH en 25,5 miljoen USDC uit de bridge weggehaald.
• Harmony Horizon Bridge: in juni 2022 werden minstens twee private keys van bridgevalidators gecompromitteerd. Bij het incident werd ongeveer 100 miljoen dollar aan crypto buitgemaakt.
• Nomad: in augustus 2022 zorgde een fout rond de initialisatie van het Replica-contract ervoor dat onbewezen berichten als geldig konden worden behandeld. Daardoor konden verschillende adressen transacties kopiëren en assets uit de bridge halen. Het totale verlies bedroeg ongeveer 190 miljoen dollar.
• BNB Chain Token Hub: in oktober 2022 werd de native bridge tussen BNB Beacon Chain en BNB Smart Chain getroffen. Door het vervalsen van een low-level proof konden ongeveer 2 miljoen extra BNB worden gecreëerd.

De bedragen bij zulke incidenten moeten wel in context worden gezien. Een genoemd bedrag kan slaan op de marktwaarde van geminte tokens, daadwerkelijk weggehaalde reserves, tijdelijk geblokkeerde assets of bedragen die later zijn teruggehaald. Omdat cryptoprijzen bewegen, kan ook de gerapporteerde dollarwaarde per meetmoment verschillen.

Hoe kunnen cross-chain bridge exploits worden voorkomen?

Cross-chain bridge exploits zijn niet volledig te voorkomen, maar meerdere onafhankelijke beveiligingslagen kunnen de kans op een succesvolle aanval en de maximale schade verkleinen.

De basis is strikte verificatie. Een bridge moet onder meer controleren waar een bericht vandaan komt, of het geldig is, voor welke actie het bedoeld is en of het nog niet eerder is gebruikt. Pas daarna mag een contract bijvoorbeeld tokens minten of reserves vrijgeven.

Ook het trustmodel telt. Een bridge die afhankelijk is van een kleine externe validator- of multisig-set heeft een ander risicoprofiel dan een bridge die cross-chain informatie via bijvoorbeeld light clients verifieert. Geen enkel ontwerp is volledig zonder risico.

Verder kunnen maatregelen helpen om de maximale schade te beperken:

• Rate limits beperken hoeveel waarde binnen een bepaalde periode kan worden verplaatst.
• Opnameplafonds stellen een maximum aan uitbetalingen.
• Circuit breakers kunnen afwijkende activiteit automatisch afremmen of stoppen.
• Pause-functies kunnen bepaalde bridgeactiviteiten tijdelijk stilleggen tijdens een incident.
• Monitoring kan opvallend grote of ongebruikelijke bridgeberichten sneller signaleren.

Zo'n noodrem lost de onderliggende kwetsbaarheid niet op. Hij kan wel voorkomen dat een aanvaller in korte tijd alle beschikbare reserves wegneemt.

Audits, bug bounties, code reviews en uitgebreide tests zijn eveneens belangrijk. Ze werken het beste in combinatie met continue monitoring, veilig sleutelbeheer en een incidentplan dat vooraf is voorbereid.

Welke beveiligingsmaatregelen kunnen ontwikkelaars nemen?

Ontwikkelaars kunnen het risico verkleinen door verificatie, toegangsrechten, sleutelbeheer en noodmaatregelen vanaf het begin streng in te richten.

1. Controleer ieder bericht volledig. Controleer onder meer de bronblockchain, afzender, nonce of unieke message ID, bestemming en toegestane functie. Zo voorkom je dat een bericht van de verkeerde bron komt of voor een andere actie wordt hergebruikt.

2. Bouw replaybescherming in. Markeer een verwerkt bericht als gebruikt en accepteer het niet opnieuw. Dit helpt tegen replay attacks, waarbij dezelfde opdracht meerdere keren wordt uitgevoerd.

3. Geef zo min mogelijk rechten. Gebruik het principe van least privilege. Niet ieder account hoeft contracten te kunnen upgraden, validators te wijzigen, tokens te minten of een noodstop te activeren. Hoe minder bevoegdheden één account heeft, hoe kleiner de potentiële schade als het wordt gecompromitteerd.

4. Bescherm beheeraccounts met een multisig. Gebruik voor gevoelige beheerhandelingen waar passend meerdere onafhankelijke ondertekenaars in plaats van één externally owned account met één private key. Een multisig is daarbij alleen nuttig als de ondertekenaars en hun sleutels daadwerkelijk voldoende onafhankelijk zijn.

5. Gebruik een timelock voor risicovolle wijzigingen. Een timelock bouwt een wachttijd in voordat een upgrade of governancebesluit wordt uitgevoerd. Daardoor kunnen wijzigingen vooraf worden gecontroleerd en kan verdachte activiteit eerder worden opgemerkt.

6. Test meer dan alleen de normale route. Laat onafhankelijke audits uitvoeren, maar test ook upgrades, initialisatie, foutieve invoer, grensgevallen en bewijsverificatie. De Nomad-exploit laat zien hoe ernstig een fout bij een upgrade of initialisatie kan uitpakken.

7. Bereid incidentrespons vooraf voor. Gebruik monitoring, afwijkingsdetectie, rate limits en waar passend een gecontroleerde noodstop. Leg vooraf vast wie mag ingrijpen, welke acties mogelijk zijn en hoe tijdens een incident wordt gecommuniceerd.

8. Beheer private keys zorgvuldig. Houd sleutels van validators en beheerders gescheiden en goed beveiligd. Zorg daarnaast voor procedures waarmee ondertekenaars gecontroleerd kunnen worden toegevoegd, verwijderd en vervangen.

Een audit of bug bounty is daarbij geen veiligheidskeurmerk. Nieuwe upgrades, off-chain relayers, configuratiewijzigingen en de dagelijkse beveiliging van private keys blijven afzonderlijke risico's.

Hoe kunnen gebruikers risico’s beperken?

Je kunt als gebruiker de beveiliging van een bridge niet zelf bepalen, maar je kunt wel beperken hoeveel risico je via een bridge neemt.

1. Kijk naar het trustmodel. Controleer welke bridge je gebruikt en hoe cross-chain berichten worden geverifieerd. Kijk bijvoorbeeld of een externe validatorgroep, multisig, light client of ander verificatiemodel wordt gebruikt.

2. Gebruik de juiste interface. Open de bridge via een betrouwbaar en gecontroleerd projectkanaal. Controleer voordat je een transactie ondertekent onder meer de URL, blockchain, het ontvangstadres en de token die je verstuurt.

3. Onderteken niet blind. Controleer wat een transactie of bericht doet voordat je het ondertekent. Blind signing kan je blootstellen aan phishing, een kwaadwillend contract of ongewenste toestemmingen.

4. Beperk token approvals. Geef waar mogelijk alleen toestemming voor het bedrag dat nodig is. Een token approval kan on-chain actief blijven totdat deze wordt gewijzigd of ingetrokken.

5. Trek ongebruikte approvals in. Controleer oude spending caps en trek ze in als je ze niet meer nodig hebt. Alleen je crypto wallet loskoppelen van een dApp verwijdert bestaande token approvals niet.

6. Beperk je blootstelling. Een kleine testtransactie kan helpen om bijvoorbeeld het adres, de interface en de gekozen route te controleren. Zo'n test bewijst echter niet dat de bridge zelf veilig is.

7. Houd rekening met het risico van bridged tokens. Na een exploit kunnen wrapped tokens tijdelijk moeilijk inwisselbaar of minder liquide worden. Hoe langer en hoe meer waarde via één bridge afhankelijk blijft van de onderliggende reserves, hoe groter de blootstelling aan dat specifieke bridge-risico.

Controleer daarnaast actuele officiële incidentmeldingen en veiligheidswaarschuwingen voordat je een bridge gebruikt.

Conclusie

Een cross-chain bridge maakt het mogelijk om tokens, berichten en andere data tussen blockchains uit te wisselen, maar voegt daarbij ook een extra beveiligingslaag toe. Kwetsbaarheden kunnen onder meer ontstaan in de verificatie van cross-chain berichten, toegangsrechten, private keys, configuratie en smart contracts.

De gevolgen kunnen groot zijn, omdat bridges vaak aanzienlijke hoeveelheden crypto beheren of verantwoordelijk zijn voor de dekking van wrapped tokens. Incidenten bij onder andere Poly Network, Wormhole, Ronin, Harmony, Nomad en BNB Chain laten bovendien zien dat bridge exploits op heel verschillende manieren kunnen ontstaan.

Voor ontwikkelaars draait goede beveiliging daarom om meerdere onafhankelijke lagen: strikte verificatie, replaybescherming, beperkt beheer, veilig sleutelbeheer, monitoring en een voorbereid incidentplan. Voor gebruikers is het vooral belangrijk om te begrijpen welk trustmodel een bridge gebruikt, de juiste interface te controleren en rekening te houden met de extra risico's van bridged assets.

Bridges spelen een belangrijke rol in een ecosysteem met meerdere blockchains, maar zijn niet zonder risico. Hoe beter je begrijpt hoe een bridge gebeurtenissen op een andere blockchain controleert en van welke partijen of systemen die verificatie afhankelijk is, hoe beter je het beveiligingsmodel ervan kunt beoordelen.