Heute wurde das Netzwerk von einem Transaktions -Spam -Angriff angegriffen, der wiederholt als Extcodesize -Opcode bezeichnet wird (siehe Trace -Probe Hier) und erstellen Sie damit Blöcke, die bis zu ~ 20-60 Sekunden dauern, um zu validieren, da die für die Verarbeitung der Transaktion benötigten ~ 50.000 Festplatten-Abrufe erforderlich sind. Das Ergebnis davon war eine ~ 2-3x-Verringerung der Blockschöpfungsrate, während der Angriff stattfand; Es gab keinen Konsensausfall (dh Netzwerkgabel) und weder das Netzwerk noch ein Client zu irgendeinem Zeitpunkt, an dem sie vollständig angehalten wurden. Der Angriff hat seitdem zum Zeitpunkt dieses Schreibens größtenteils gestoppt, und das Netzwerk wurde vorerst wiederhergestellt.
Die kurzfristige Lösung besteht für Benutzer, einschließlich Bergarbeiter, Unternehmensbenutzer (einschließlich Börsen) und Einzelpersonen, die Geth mit den Flags betreiben:
-Cache 1024–Targetgaslimit 1500000-Gasprice 20000000000
Oder Parität mit den Flaggen:
-Cache-Größe-DB 1024-Gas-Floor-Target 1500000-Gasprice 20000000000-Gas-Cap 1500000
Dies (i) erhöht die Cache -Größe und verringert die Anzahl der Festplatten, die die Knoten machen müssen, und (ii) stimmt die Gasgrenze um ~ 3x ab, wodurch die maximale Verarbeitungszeit eines Blocks um einen ähnlichen Faktor verkürzt wird.
Mittelfristig (dh mehrere Tage bis zu einer Woche) arbeiten wir aktiv an mehreren Korrekturen für den GO -Kunden, der beide eine stabilere Lösung für das vorliegende Problem bieten und das Risiko ähnlicher Angriffe mildern sollte, einschließlich:
- Eine Änderung der Miner -Software, die das Ziel der Gasgrenze automatisch um 2x senkt, wenn der Bergmann einen Block sieht, der länger als 5 Sekunden dauert, um Anpassungen zu ermöglichen, die ähnlich wie die heutigen Koordinierung automatisch auftreten (siehe Hier für eine Pull -Anfrage; Beachten Sie, dass dies eine Miner -Strategie -Änderung ist und keine Softgabel oder eine Hardgabelung).
- Numerische Änderungen an Cache -Einstellungen
- Hinzufügen zusätzlicher Caches
- Hinzufügen eines zusätzlichen Cache für extcodesize speziell (da es wahrscheinlich ist, dass Extcodesize-Lesevorgänge mehrmals langsamer sind als andere IO-strenge Operationen, da die gelesenen Verträge ~ 18 kb lang sind)
- Ein Auftragscache von Zustandswerten, der es ihnen ermöglicht, schneller zu sein (dh. O (log (n)) Beschleunigung) Zugriff
Wir untersuchen auch die Möglichkeit, die LevelDB -Datenbank durch etwas Performantes und optimierteres für unseren Anwendungsfall zu ersetzen, obwohl eine solche Änderung nicht bald vorhanden wäre. Das Parity -Team arbeitet an ihren eigenen Leistungsverbesserungen.
Langfristig gibt es Protokolländerungen mit niedrigem Niveau, die ebenfalls untersucht werden können. Zum Beispiel kann es ratsam sein, Metropolis eine Funktion hinzuzufügen, um die Gaskosten von Opcodes zu erhöhen, für die Lesevorgänge des Kontostatus (Sload, Extcodieren, Anrufe usw.) und insbesondere Vorgänge mit der Aufschrift externer Konten erforderlich sind. Die Erhöhung der Gaskosten aller dieser Operationen auf mindestens 500 wäre wahrscheinlich ausreichend, obwohl darauf geachtet werden müsste, um zu vermeiden EIP 90 würde ausreichen).
Dies würde eine viel untere Obergrenze auf die maximale Anzahl von Bytes geben, die eine Transaktion lesen kann, wodurch die Sicherheit gegen alle möglichen Angriffe dieser Art erhöht und die Größe von Merkle -Proofs verringert und somit die Sicherheit für leichte Kunden und das Sharding als Nebeneffekt verbessert. Gegenwärtig konzentrieren wir uns auf die sofortigeren Änderungen auf Softwareebene. Langfristig sollten jedoch solche Vorschläge diskutiert werden und die Vertragsentwickler sollten sich bewusst sein, dass Änderungen dieser Art stattfinden können.
