Ik ben nooit een fan geweest van Solidity. Het is een slecht ontworpen taal om veel redenen, maar het blijft de ruggengraat van @ethereum. Wat me het meest zorgen baart, is dat veel van de kernhulpmiddelen en bibliotheken die eromheen zijn gebouwd, mogelijk geen langdurige ondersteuning hebben. Zelfs de nieuwe Solidity-compiler wordt momenteel onderhouden door een klein aantal ontwikkelaars (tweede afbeelding). Dit is niet alleen een economisch probleem, het is ook een technisch probleem. Het bouwen en onderhouden van grote, kritieke systemen vereist tijd, continuïteit en diepgaande expertise. Die dingen kunnen niet van de ene op de andere dag worden vervangen. Ik heb ook geleerd dat verschillende L2- en ZK-bedrijven stilletjes aan het afbouwen zijn of dit overwegen in de komende maanden. Dit is ook zorgwekkend omdat het lijkt alsof slechts een handvol bedrijven de expertise en economische mogelijkheden zal hebben om een zkVM op de lange termijn te onderhouden. Als Ethereum afhankelijk is van ZK, moeten we manieren vinden om deze tools te blijven ontwikkelen, zodat we niet alleen afhankelijk zijn van een of twee leveranciers. Een ander dreigend risico is wat er gebeurt wanneer de gaslimiet wordt verhoogd. Veel uitvoeringsclients hebben hun prestaties niet significant verbeterd, en op basis van hun repositories betwijfel ik of ze in staat zullen zijn om bij te blijven. De technische schuld van Ethereum blijft groeien, niet alleen vanwege constante en noodzakelijke protocolontwikkeling, maar ook omdat een groot aantal afhankelijkheden en repositories stagnatie vertoont. Het ecosysteem blijft schalen, waarbij miljarden dollars aan activa worden beveiligd, terwijl delen van de basis eroderen.