Agave-4.1-Update: Alles, was du wissen musst

Einführung

Mit Agave 4.1 entwickelt sich Solanas zentraler Validator-Client stetig weiter. Das Release verbessert schon heute die Leistung und schafft zugleich die Grundlage für größere Blöcke, Slot-Zeiten von 200 ms und die spätere Einführung von Alpenglow.

Wichtige Neuerungen im 4.1-Release-Zyklus

• Schnellere Release-Frequenz mit neuen Hauptversionen alle sechs Wochen
• Weitere Vorbereitungen auf Alpenglow, darunter die Verwaltung öffentlicher BLS-Schlüssel*, Validator Admission Tickets* und der Community-Test-Cluster
• XDP-Nutzung überschreitet einen kritischen Netzwerkschwellenwert
• Weitere Neuentwicklungen mit Pinocchio, darunter p-memo und p-ATA
• Geringerer RAM-Verbrauch der Validatoren
• Vorbereitung auf Slot-Zeiten von 200 ms**

* Durch Feature Gates gesteuerte Upgrades

** Erwartet in Agave 4.2

Parallel zur Arbeit am zentralen Client treiben Anza und das breitere Ökosystem mehrere große Initiativen voran:

• Constellation: Constellation schlägt die erste formale Implementierung von Multiple Concurrent Proposers (MCP) auf Protokollebene in einer produktiven Blockchain dieser Größenordnung vor. Statt einem einzelnen Leader weitreichenden Ermessensspielraum bei der Aufnahme von Transaktionen zu geben, führt Constellation Proposer und Attester ein. Diese schränken ein, was der Leader aus einem gültigen Block ausschließen kann.
• Absicherung gegen Quantencomputer: Das Forschungsteam von Anza untersucht seit Kurzem, wie sich Solana absichern lässt, um zukünftigen Angriffen durch Quantencomputer standzuhalten. Dazu gehören Forschungen zu Post-Quanten-Signaturen, Account-Migrationen, Konsenssignaturen, Blockweitergabe und der Onchain-Verifizierung von Signaturen.
• Wirtschaftliche Upgrades: Eine neue Welle von Tokenomics-Vorschlägen ist ebenfalls in Vorbereitung. SIMD-550 schlägt vor, Solanas Disinflationsrate zu verdoppeln – von -15 % auf -30 %. SIMD-553: Ressourcen- und Aufnahmegebühr schlägt dagegen vor, die heutige Signaturgebühr in eine an den Leader gezahlte Grundgebühr für die Aufnahme und eine verbrannte Ressourcengebühr auf Basis der angeforderten Kosteneinheiten aufzuteilen.
• Neue Governance-Werkzeuge: Verbesserte Governance-Infrastruktur prägt auch die nächste Runde wirtschaftlicher Vorschläge. Mit neuen Werkzeugen können sich nicht nur Validatoren, sondern auch Staker direkt an Solanas Governance beteiligen. So können mehr Akteure über Änderungen am Kernprotokoll mitentscheiden.

Gerade passiert unglaublich viel.

Ob du einen Validator betreibst oder entwickelst: Dieser Leitfaden liefert dir die nötigen Updates und Einblicke, damit du die neuesten Verbesserungen optimal nutzen kannst. Jeder Abschnitt des Artikels ist eigenständig, sodass du dich auf die für dich relevantesten Themen konzentrieren kannst. 

Zum Zeitpunkt der Veröffentlichung wird Agave v4.1.0-rc.1 für den allgemeinen Einsatz im Mainnet empfohlen. Validatoren, jetzt ist es Zeit für das Upgrade!

Vorbereitung auf Alpenglow

Ein großer Teil der Grundlagen für das Alpenglow-Konsens-Upgrade kommt während des Release-Zyklus von Agave 4.1. Diese Änderungen bereiten das Netzwerk auf den Wechsel von Tower BFT zu Alpenglow vor. Dazu gehören die Verwaltung von BLS-Schlüsseln im Vote-Programm, Validator Admission Tickets und Marker für Fast Leader Handover.

Community-Test-Cluster

Der verbleibende Weg zur Mainnet-Aktivierung von Alpenglow hängt nun stark von umfangreichen Praxistests ab. Seit Mai führt ein Community-Test-Cluster mit rund 100 geografisch verteilten Validatoren das Upgrade in einer Live-Netzwerkumgebung aus. Dabei wird vor der Mainnet-Aktivierung der Wechsel zwischen Solanas aktuellem, auf Tower BFT basierendem Konsens und Alpenglow getestet.

Der Start soll so ereignislos wie möglich verlaufen. Die Validatoren im Cluster wechseln zwischen Tower BFT und Alpenglow. So testen sie den Migrationspfad unter realen Betriebsbedingungen, statt sich ausschließlich auf kontrollierte interne Tests zu verlassen. Diskussionen finden im Kanal `ag-community-cluster` auf dem Solana-Tech-Discord statt. Die Live-Aktivität des Clusters kannst du über Community-Dashboards von Valid Blocks, Staking Facilities und Noders verfolgen.

Verwaltung öffentlicher BLS-Schlüssel

SIMD-0387: Verwaltung öffentlicher BLS-Schlüssel im Vote-Account wird während des Release-Zyklus von Agave 4.1 aktiviert. Damit erhält das Vote-Programm die nötige Infrastruktur, damit Validatoren vor der Einführung von Alpenglow öffentliche BLS-Schlüssel in ihren Vote-Accounts registrieren können. Alpenglow verwendet aggregierte BLS-Signaturen, um Votes günstiger zu aggregieren und zu verifizieren. Öffentliche BLS-Schlüssel unterscheiden sich jedoch von den heute verwendeten Ed25519-Schlüsseln der Vote Authority. 

Validatoren können öffentliche BLS-Schlüssel zu ihren Vote-Accounts hinzufügen und zugleich ihre bestehenden Ed25519-Schlüssel der Vote Authority weiterverwenden. Sobald Alpenglow aktiv ist, können Vote-Accounts ohne registrierten öffentlichen BLS-Schlüssel nicht am neuen Abstimmungsprozess teilnehmen.

Alpenglow Validator Admission Tickets (VAT)

Zum Release-Zyklus von Agave 4.1 gehört auch die Mainnet-Aktivierung von SIMD-0357, das Validator Admission Tickets (VAT) implementiert. VATs sollen eine ähnliche Kostenstruktur für Validatoren erhalten, wenn Solana das aktuelle Modell der Vote-Transaktionen unter Tower BFT ablöst.

Heute zahlen Validatoren bei jeder Abstimmung fortlaufend Gebühren für Vote-Transaktionen. Für Validatoren, die regelmäßig abstimmen, summieren sich diese auf ~2,1 SOL pro Epoche. Unter Alpenglow ersetzt ein neues Konsensdesign diese Vote-Transaktionen. Daher führt SIMD-0357 stattdessen einmal pro Epoche anfallende Zulassungskosten ein. Jeder Validator, der zur Teilnahme an Alpenglow-Abstimmungen berechtigt ist, zahlt pro Epoche ein VAT von 1,6 SOL. So bleibt eine vergleichbare wirtschaftliche Hürde bestehen und das Risiko einer sofortigen, unkontrollierten Ausweitung des Validator-Sets nach dem Start von Alpenglow sinkt.

Die Umsetzung erfolgt an der Epochengrenze. Beim Wechsel in eine neue Epoche berechnet die Runtime das Validator-Set für die nächste Epoche. Sie filtert nach Vote-Accounts, die sowohl einen registrierten öffentlichen BLS-Schlüssel als auch genügend Lamports für VAT und Rent besitzen. Anschließend zieht sie das VAT von den Vote-Accounts der zugelassenen Validatoren ab. Diese Lamports gehen direkt an den Incinerator-Account. Qualifizieren sich mehr als 2.000 Validatoren, wird das Abstimmungs-Set nach Stake-Gewicht begrenzt und die am höchsten gewichteten berechtigten Validatoren werden ausgewählt.

Für den Betrieb ändert sich dadurch, wo Validator-Betreiber Guthaben vorhalten müssen. Gebühren für Vote-Transaktionen werden derzeit vom Identity-Account des Validators bezahlt. Dieser muss für den normalen Validator-Betrieb ein Hot Keypair sein. Bei VATs werden die Zulassungskosten stattdessen vom Vote-Account abgezogen.

Marker für Fast Leader Handover

Die Aktivierung von SIMD-0337: Marker für Alpenglow Fast Leader Handover fügt schließlich neue Block-Marker hinzu. Mit ihnen kann ein Alpenglow-Leader zu Beginn eines Blocks dessen Parent angeben und ihn bei Bedarf während des Streamings des Blocks aktualisieren. Diese Marker unterstützen Fast Leader Handover, das Synchronisierungsverzögerungen zwischen Leadern reduzieren soll.

Breitere XDP-Nutzung und der Weg zu 100 Millionen CUs

XDP (eXpress Data Path) ist der leistungsstarke Netzwerkpfad, mit dem Agave Turbine beschleunigt. Agave kann damit ein eBPF-Programm nahe an der Netzwerkkarte laden. So umgeht der Shred-Datenverkehr einen Großteil der üblichen Linux-Paketverarbeitung. Die Nutzung von XDP ist entscheidend, damit das Netzwerk sein langjähriges Ziel von Blöcken mit 100 Millionen CUs erreicht. 

Die Nutzung hat inzwischen einen wichtigen Schwellenwert überschritten. Anfang dieses Monats erlebte das Netzwerk das „Flippening“: Erstmals nutzten mehr Leader XDP als nicht. Derzeit haben mehr als zwei Drittel des Netzwerks XDP aktiviert. Agave 4.1 trägt diesem Reifegrad Rechnung. Es entfernt die experimentelle Kennzeichnung der XDP-Unterstützung und ersetzt die alten Flags `--experimental-retransmit-xdp-*` durch `--xdp-interface`, `--xdp-cpu-cores` und `--xdp-zero-copy`. In Agave 4.2 soll XDP standardmäßig aktiviert sein.

Validator-Betreiber, die noch nicht umgestiegen sind, finden auf der Upgrade-Seite der Solana Foundation und in Anzas Einrichtungsleitfaden eine praktische Kompatibilitätscheckliste. Sie behandelt Kernel-Unterstützung, Netzwerkhardware, Validator-Funktionen, Start-Flags und Verifizierungsschritte. Unten findest du einen hilfreichen Kompatibilitätsleitfaden für Treiber und NICs.

Weitere mit Pinocchio neu entwickelte Programme

Der erfolgreiche Start von p-token hat kürzlich gezeigt, dass gezielte Neuentwicklungen der meistgenutzten Solana-Programme im gesamten Netzwerk erhebliche Rechenressourcen sparen können. Als direkter Ersatz für das SPL-Token-Programm reduziert p-token den Verbrauch von Compute Units (CU) um etwa 95 %. Das entspricht einer rund ~19-fachen Effizienzsteigerung bei Standard-Token-Transaktionen. Anweisungen des Token-Programms machten zuvor etwa 10 % der blockweiten CU-Nutzung aus. Indem p-token die Kosten dieser Anweisungen auf ungefähr 5 % ihres vorherigen Werts senkte, wurden fast 9,5 % der gesamten Blockkapazität frei.

Das „p“ in p-token steht für Pinocchio, eine von Anza entwickelte, optimierte, leistungsstarke Bibliothek ohne Abhängigkeiten zum Schreiben von Solana-Programmen. Pinocchio ersetzt das standardmäßige solana-program-Crate, das für die Verarbeitung von Anweisungs- und Account-Daten umfassend Zero-Copy-Typen nutzt.

Anza entwickelt nun weitere Kernprogramme mit Pinocchio neu. Das Ziel besteht nicht darin, neue Standards einzuführen oder Migrationen auf Anwendungsebene zu erzwingen. Vielmehr sollen bestehende, weitverbreitete Programme deutlich günstiger ausgeführt werden können.

P-memo-Programm

Das erste Beispiel ist p-memo, eine Pinocchio-Neuimplementierung des SPL-Memo-Programms, die bereits im Mainnet läuft. Das Memo-Programm ist klein, doch die Effizienzgewinne sind beeindruckend. Ohne Signer verbraucht p-memo 287 CUs, verglichen mit 2.022 CUs beim aktuellen Memo-Programm. Das sind etwa 14 % der bisherigen Kosten. Mit Signern wird der Unterschied noch deutlicher: Bei einem Signer nutzt p-memo 513 statt 13.525 CUs, bei zwei Signern 628 statt 25.111 CUs und bei drei Signern 743 statt 36.406 CUs. In Fällen mit vielen Signern reduziert p-memo den Rechenaufwand damit auf nur 2–4 % der Kosten des aktuellen Programms.

P-ATA-Programm

Auch an p-ATA wird gearbeitet, einer Pinocchio-Neuimplementierung des Associated-Token-Account-Programms. Das ATA-Programm definiert die standardmäßige Zuordnung zwischen einer Wallet, einem Token-Mint und dem Token-Account, der diesen Mint hält. Es ermöglicht, den zugehörigen Token-Account eines Benutzers deterministisch abzuleiten. Zudem kann jeder diesen Account für einen Empfänger erstellen, falls er noch nicht existiert. 

Das ATA-Programm ist das am fünfthäufigsten aufgerufene Programm im Netzwerk. Nach Schätzungen des Anza-Teams kommt es in ~11,9 % aller Transaktionen vor und verursacht ~13,3 % des gesamten CU-Verbrauchs. Die Neuentwicklung könnte die gewichtete durchschnittliche CU-Nutzung um 80,9 % senken. Weitere Einsparungen werden durch neue Anweisungen erwartet, die zusammen mit p-ATA hinzukommen. Bei der aktuellen Netzwerknutzung entspräche das einer globalen CU-Einsparung von rund 10 % im Mainnet. In Anzas Stichprobe setzte p-ATA mehr als 2,78 Millionen CUs pro Block frei.

P-token, p-memo und p-ATA dürften nicht das Ende dieser Arbeit sein. Das Token-2022-Programm ist ein weiteres häufig gewünschtes Programm. Allgemeiner betrachtet schafft Anzas Initiative, Kernprogramme `no_std` zu machen, die Grundlage dafür, weitere zentrale Solana-Programme mit weniger Abhängigkeiten und geringeren Rechenkosten neu zu entwickeln.

Weniger Overhead am Programmeinstiegspunkt

Eine verwandte Änderung, die während des Release-Zyklus von Agave 4.1 aktiviert werden soll, ist SIMD-0449: Direkte Account-Pointer in der Programmeingabe. Sie optimiert den Programmeinstiegspunkt. Heute müssen ABIv1-sBPF-Programme den serialisierten Account-Abschnitt der Programmeingabe parsen, um Account-Grenzen zu finden und den an das Programm übergebenen Account-Slice zu erstellen. SIMD-0449 ändert dies: Die VM hängt einen Slice mit direkten Account-Pointern an die Programmeingabe an. Dafür nutzt sie Grenzinformationen, die ihr bei der Vorbereitung des Aufrufs bereits bekannt sind.

Das ist für Programme im Pinocchio-Stil besonders relevant, da das Parsen von Accounts einen großen Teil der Kosten am Einstiegspunkt ausmacht. Mit direkten Account-Pointern kann der Einstiegspunkt auf Accounts zugreifen, ohne den gesamten Account-Abschnitt zu durchlaufen. Dadurch bleibt der Rechenaufwand am Einstiegspunkt unabhängig von der Anzahl der Accounts praktisch konstant. 

In den aktualisierten Benchmarks sinkt der Verbrauch eines Pinocchio-Einstiegspunkts mit 64 Accounts von 504 CUs auf geschätzte 7 CUs. Auch kleinere Account-Sets nähern sich denselben niedrigen Kosten von 7 CUs an.

Kürzere Slot-Zeiten von 200 ms

Eine der am meisten erwarteten Leistungsverbesserungen ist die Verkürzung von Solanas angestrebter Slot-Zeit von 400 ms auf 200 ms. Sie wird voraussichtlich nicht während des Release-Zyklus von Agave 4.1 eingeführt, sondern eher mit Agave 4.2 ins Mainnet kommen. Der Impuls wächst jedoch, dieses wichtige Upgrade so schnell wie möglich ins Mainnet zu bringen.

SIMD-0525: Slot-Zeiten reduzieren schlägt eine stufenweise Einführung vor: von Slots mit 400 ms zunächst auf 350 ms, dann auf 300 ms und 250 ms und schließlich auf 200 ms. Jede Stufe wird durch ein Feature Gate gesteuert. So können Client-Teams und Betreiber das Netzwerk mit kürzeren Slot-Zeiten beobachten, bevor sie zur nächsten Stufe wechseln. Anza testet 200-ms-Slots intern bereits seit Monaten. Das Team hält das Netzwerk für bereit, die Slot-Zeiten deutlich zu verkürzen. Verbesserungen an der Replay-Phase machen die Änderung praktikabler: Das Replay eines vollständigen 400-ms-Slots dauert jetzt etwa 40 ms.

Die Motivation ist einfach. Kürzere Slots reduzieren die Latenz bei Bestätigung und Finalisierung für Benutzer. Außerdem verkürzen sie das Zeitfenster jedes Leaders. Heute umfasst Solanas Leader-Phase vier aufeinanderfolgende Slots. Bei Slots von 400 ms hat ein Leader somit ein Zeitfenster von 1,6 Sekunden. Bei Slots von 200 ms sinkt dieses Fenster auf 800 ms. Das verbessert die Marktstruktur, da ein böswilliger Leader Transaktionen im schlimmsten Fall weniger lange verzögern, umordnen oder selektiv aufnehmen kann, bevor der nächste Leader einen Block erstellen darf.

Kürzere Slots ermöglichen Anwendungen außerdem eine feiner aufgelöste Onchain-Zeitmessung. Das ist wichtig für Systeme, die die Aktualität von Slots berücksichtigen, darunter Oracle-Nutzer und proprietäre Market Maker im AMM-Stil.

Der Vorschlag ist so konzipiert, dass Solanas wirtschaftliches Modell unverändert bleibt. `slots_per_year` wird um das umgekehrte Verhältnis erhöht, wodurch der SOL-Inflationsplan erhalten bleibt. Unter Alpenglow skalieren auch die Kosten für Validator Admission Tickets (VAT) mit der Slot-Zeit-Stufe. Dadurch bleiben die Zulassungskosten nahe dem vorgesehenen Wert von ~0,8 SOL pro Tag. Zusätzlich werden die Arbeitslimits pro Slot proportional zur kürzeren Ziel-Slot-Zeit reduziert. Die Arbeitsmenge, die das Netzwerk pro Sekunde verarbeiten kann, bleibt damit ungefähr unverändert. 

Mehrere zentrale Annahmen bleiben unverändert. Leader-Phasen umfassen weiterhin vier Slots, Epochen bleiben auf 432.000 Slots festgelegt und die Anzahl der Ticks pro Slot bleibt bei 64. Da die Slot-Anzahl pro Epoche unverändert bleibt, verkürzen 200-ms-Slots eine Epoche von etwa zwei Tagen auf einen Tag.

Umstritten ist unter anderem, wie sich kürzere Slot-Zeiten auf die Abstimmungskosten der Validatoren auswirken, wenn sie vor Alpenglow aktiviert werden. Schnellere Slots bedeuten mehr Votes pro Tag und damit höhere tägliche Abstimmungskosten für Validatoren. Vote-Transaktionen sind der größte Einzelkostenfaktor für Validator-Betreiber. Ihr einheitlicher Preis beträgt 0,000005 SOL. Pro Tag summieren sich diese Transaktionskosten auf ~1,086 SOL. Bei Slots von 200 ms würden sich diese Kosten ungefähr verdoppeln.

Weitere wichtige Neuerungen

Mehrere kleinere, aber wichtige Verbesserungen sollen während des Release-Zyklus von Agave 4.1 aktiviert werden. Sie reichen von präziseren Provisionssätzen für Validatoren über neue kryptografische Primitive bis zur Beseitigung eines Denial-of-Service-Angriffsvektors im Upgradeable Loader.

Präzisere Provisionssätze für Validatoren

Im Release-Zyklus von Agave 4.1 wird das durch ein Feature Gate gesteuerte Upgrade SIMD-0291: Provisionssatz in Basispunkten im Mainnet aktiviert. Heute lassen sich Provisionssätze von Validatoren nur in ganzen Prozentpunkten festlegen. Ein Validator kann seine Provision also auf 5 % oder 6 % setzen, nicht aber auf 5,5 %, 5,25 % oder 5,01 %.

Mit diesem Update erhalten Validatoren eine feinere Kontrolle, indem sie Provisionssätze in Basispunkten festlegen können. Dabei entsprechen 100 Basispunkte 1 %. Das Vote-Programm fügt eine neue Anweisung namens `UpdateCommissionBps` hinzu. Damit kann der autorisierte Abhebungsberechtigte eines Vote-Accounts die Provision des Validators auf Inflationsbelohnungen mit höherer Präzision aktualisieren. Validatoren können ihre Provisionen dadurch flexibler und wettbewerbsfähiger festlegen.

Diese Änderung ist eines von mehreren Updates im Zusammenhang mit dem neuen Vote Account V4. Sie bereitet das Netzwerk außerdem auf die erwartete Aktivierung von SIMD-0123: Verteilung von Blockeinnahmen vor. Damit können Blockbelohnungen direkt im Protokoll verteilt werden.

SHA-512-Syscall

SIMD-0512: SHA-512-Syscall führt einen neuen Syscall ein, der Onchain-Programmen über die Runtime direkten Zugriff auf SHA-512-Hashing gibt. Die Schnittstelle entspricht bestehenden Hash-Syscalls wie `sol_sha256`, `sol_keccak256` und `sol_blake3`.

SHA-512 ist ein zentrales Primitiv für die Verifizierung von Ed25519-Signaturen und bereits eine interne Abhängigkeit der Validator-Clients Agave und Firedancer. Bisher stand es Onchain-Programmen jedoch nicht zur Verfügung. Das direkte Onchain-Hashing einer kurzen Nachricht ist teuer und verbraucht Tausende CUs, gegenüber weniger als 100 CUs über einen Syscall.

Mit `sol_sha512` können Programme SHA-512-Hashes zu Syscall-Kosten berechnen und direkt den standardmäßigen 64-Byte-Digest erhalten. Die Änderung ist additiv und durch ein Feature Gate gesteuert. Programme, die den neuen Syscall nicht verwenden, bleiben daher unberührt. Auch bestehende Hash-Syscalls ändern sich nicht.

Absicherung des Upgradeable Loaders

Im Release-Zyklus von Agave 4.1 erscheint außerdem die durch ein Feature Gate gesteuerte Version von SIMD-0431: Loader V3: Mindestgröße für Programmerweiterungen. Sie ergänzt die Anweisung `ExtendProgram` von Loader V3 um eine Mindestgröße für Erweiterungen. Nach der Aktivierung müssen Programme um mindestens 10.240 Byte (10 KiB) erweitert werden. Eine Ausnahme gilt, wenn der Programmdaten-Account bereits höchstens 10 KiB unter der maximalen Account-Größe von 10 MiB liegt.

Diese Änderung schließt einen subtilen Denial-of-Service-Angriffsvektor im aktuellen Upgradeable Loader. `ExtendProgram` ist erlaubnisfrei. Das bedeutet, dass jeder den Daten-Account eines aktualisierbaren Programms erweitern kann, selbst um nur ein Byte. Da jede Erweiterung den Cache-Eintrag des Programms für den aktuellen Slot ungültig macht, kann eine günstige Erweiterung um ein Byte den Zugriff auf das Programm vorübergehend stören.

Statt `ExtendProgram` mit Berechtigungen zu versehen, behält die Änderung das erlaubnisfreie Design der Anweisung bei und macht Missbrauch wirtschaftlich unattraktiv. Bei der neuen Mindestgröße von 10 KiB kostet jede Erweiterung rund 0,072 SOL an Rent-befreiten Lamports.

Bei legitimen Programm-Upgrades sollten die Auswirkungen begrenzt bleiben. Programme, die weniger als 10 KiB zusätzlichen Speicher benötigen, müssen um die volle Mindestgröße erweitert werden. Die zusätzliche Kapazität bleibt jedoch für zukünftige Upgrades verfügbar. Auch die Accounts der Anweisungen, Signer-Anforderungen, CPI-Einschränkungen und bestehenden Multisig-Workflows bleiben durch das SIMD unverändert.

Fazit

Agave 4.1 ist ein umfangreiches Client-Upgrade, das zahlreiche Leistungsverbesserungen und Optimierungen vereint. Agave 4.2 dürfte noch weitreichender werden: mit größeren Transaktionen von 4.096 Byte, kürzeren Slot-Zeiten von 200 ms und möglicherweise dem lang erwarteten Alpenglow-Konsens-Upgrade.

Weitere Ressourcen

• Release-Zeitplan für Agave 4.1
• Zeitplan des Feature-Gate-Trackers
• Änderungsprotokoll für Agave 4.1
• Pull Requests für Agave 4.1