Geschrieben von: Peter
Vorwort
Seit der Einführung von BTC im Jahr 2009 hat sich Bitcoin, das drei technologische Iterationen durchlaufen hat, von einem einfachen Digital-Native-Asset-Konzept zu einem dezentralen Finanzsystem mit komplexen Funktionen und Anwendungen entwickelt.
Dieser Artikel wurde vom Gründer von BEVM verfasst, der seine Einblicke in die Entwicklung der BTC-Technologie teilt. Außerdem wird ausführlich erläutert, wie BEVM, ein wichtiger Meilenstein in der Entwicklung der BTC Layer2-Technologie, die Zukunft von BTC auf technischer Ebene realisiert. Dezentraler ökologischer Wohlstand.
In diesem Artikel erfahren Sie mehr über:
Die Notwendigkeit von BTC Layer2
Wie implementiert man BTC Layer2?
Vollständig dezentrale BEVM-Lösung
Hommage an die drei großen revolutionären Technologie-Iterationen von BTC seit seiner Geburt:
2009: BTC wurde geboren und nutzte erstmals die Blockchain-Struktur, um dezentrale Währungsanwendungen zu eröffnen.
2017: BTC Segregated Witness wurde aktualisiert, um einen maximalen Speicher von 4 MB zu unterstützen, wodurch das On-Chain-Speicherproblem von BTC gelöst wurde. Dies bildet auch die Grundlage für das mittlerweile beliebte Ordinals-Protokoll (Ausgabe von Vermögenswerten).
2021: BTC Taproot wird aktualisiert, um den BTC-Schwellenwertsignaturalgorithmus zu unterstützen, der zugrunde liegende Unterstützung für die vollständig dezentrale BTC Layer2-Technologie bietet.
1. Warum möchten Sie BTC Layer2 aufbauen?
1. Es besteht Nachfrage: Das Bitcoin-Netzwerk erfüllt die Nachfrage nach der Registrierung von Vermögenswerten, es gibt jedoch immer noch eine große Anzahl von Vermögenswerten, die eine Abwicklung in der Kette erfordern (Schicht 2).
Die aktuelle Schicht 2 der ETH ist lediglich eine Kopie der Schicht 1 der ETH. Es gibt keine praktischen Geschäftsprobleme, die nicht durch Schicht 1 gelöst werden können und durch Schicht 2 gelöst werden müssen.
Es muss gesagt werden, dass ETH Layer2 das Problem von ETH Layer1 löst: Layer2 löst das Problem der hohen Gaskosten von Layer1. Genau aufgrund dieser Nachfrage wurden Derivateanwendungen auf dem größten Layer2-Arbitrum der ETH wie GMX erstellt.
Und der Layer2 von BTC ist nicht so irrelevant wie der Layer2 von ETH.
Da die nicht-Turing-vollständige On-Chain-Virtual-Machine von BTC nur Vermögenswerte registrieren, aber keine Abwicklung durchführen kann, muss BTC Layer1 die Turing-vollständige BTC Layer2 benötigen, um die von BTC Layer1 ausgegebenen Vermögenswerte abzuwickeln.
2. Leistungsfähig: BTC kann zu einem vollständig dezentralen Layer 2 werden
Vor dem BTC Taproot-Upgrade im Jahr 2021 wird es unmöglich sein, eine vollständig dezentrale BTC-Schicht 2 zu erreichen. Nach diesem Upgrade ermöglicht der BTC-Schwellenwertsignaturalgorithmus BTC jedoch die Unterstützung einer vollständig dezentralen Layer-2-Rechenschicht.
Zweitens: Wie erreicht man dezentrales BTC L2?
Bitcoin Improvement Proposals (BIPs) sind Designdokumente, die neue Funktionen und Informationen zu Bitcoin einführen, während das Taproot-Upgrade eine Zusammenstellung von drei BIPs ist, nämlich Schnorr Signature (BIP 340), Taproot (BIP 341) und Tapscript (BIP 342). Drei Upgrades werden zusammen als BIP Taproot bezeichnet.
Es wird eine effizientere, flexiblere und privatere Übertragungsmethode für Bitcoin bieten und sein Kern liegt in der Verwendung von Schnorr-Signaturen und abstrakten Merkel-Syntaxbäumen.
Die Schnorr-Signatur ist ein digitales Signaturschema, das für seine Einfachheit und Sicherheit bekannt ist. Schnoor-Signaturen bieten mehrere Vorteile hinsichtlich Recheneffizienz, Speicherung und Datenschutz.
Der Nutzer bestätigt die Identität des Unterzeichners durch den öffentlichen Schlüssel und bestätigt den Vertragsinhalt durch die Daten und verifiziert so die Gültigkeit des digitalen Vertrags.
Die aggregierte Signatur von Schnorr kann mehrere Signaturdaten komprimieren und zu einer einzigen aggregierten Signatur zusammenführen.
Der Verifizierer verifiziert eine einzelne aggregierte Signatur anhand einer Liste aller signaturbezogenen Daten und öffentlichen Schlüssel. Wenn die Verifizierung erfolgreich ist, ist der Effekt gleichbedeutend mit einer unabhängigen Verifizierung aller zugehörigen Signaturen und aller bestandenen Signaturen.
Die meisten aktuellen Blockchains verwenden den ECDSA-Mehrfachsignaturalgorithmus. Für Blockdaten verwendet jeder Knoten seinen eigenen privaten Schlüssel, um eine unabhängige digitale Signatur zu generieren und diese an andere Knoten zu senden. Andere Knoten überprüfen die Signatur und schreiben sie in den nächsten Datenblock.
Wenn bei dieser Methode die Anzahl der Konsensknoten groß ist, nehmen die in jeder Konsensblockrunde gespeicherten Signaturdaten weiter zu und belegen Speicherplatz.
Immer wenn ein neuer Knoten dem Netzwerk beitritt und historische Blöcke synchronisieren muss, stellt eine große Menge an Signaturdaten eine große Herausforderung für die Netzwerkbandbreite dar.
Nach der Verwendung der Technologie für aggregierte Signaturen sammelt jeder Knoten aggregierte Signatur-Visitenkarten, die von anderen Knoten gesendet werden, und aggregiert und speichert die Signaturen dann in Fragmenten, wie in Abbildung 2 dargestellt.
Auf diese Weise erfordert die Synchronisierung historischer Blöcke beim Beitritt eines neuen Knotens nur das Herunterladen der aggregierten Signaturdaten, was die Belegung der Netzwerkbandbreite erheblich reduziert und die Transaktionsgebühren senkt.
Darüber hinaus sorgt die Schlüsselaggregation dafür, dass alle Taproot-Ausgaben ähnlich aussehen. Unabhängig davon, ob Multi-Signatur-Ausgaben, Single-Signatur-Ausgaben oder andere komplexe Smart Contracts auf der Blockchain alle gleich aussehen, werden viele Blockchain-Analysen nicht verfügbar sein, wodurch die Privatsphäre aller Taproot-Benutzer gewahrt bleibt.
MAST (Merkle Abstract Syntax Tree) verwendet einen Merkle-Baum zum Verschlüsseln komplexer Sperrskripte, dessen Blätter nicht überlappende Schiller-Skripte sind (z. B. Mehrfachsignaturen oder Zeitsperren).
Bei der Auszahlung werden nur das relevante Skript und der Pfad von diesem Skript zur Wurzel des Merck-Baums offengelegt. Wie in Abbildung 3 dargestellt, müssen Sie zur Verwendung von Skript1 nur Skript1, Skript2 und Hash3 offenlegen.
Zu den Hauptvorteilen von MAST gehören:
Unterstützt komplexe Auszahlungsbedingungen
Es besteht keine Notwendigkeit, nicht ausgeführte Skripte oder nicht ausgelöste Auszahlungsbedingungen offenzulegen, was einen besseren Schutz der Privatsphäre gewährleistet
Komprimierte Transaktionsgröße: Mit zunehmender Anzahl der Skripte wächst die Größe der Nicht-MAST-Transaktionen linear, während die Größe der MAST-Transaktionen logarithmisch wächst.
Allerdings gibt es beim Taproot-Upgrade ein Problem, das heißt, P2SH verhält sich anders als der übliche Pay-to-Public-Key-Hash (P2PKH), und es gibt immer noch Probleme beim Schutz der Privatsphäre.
Ist es möglich, dass P2SH und P2PKH in der Kette gleich aussehen?
Zu diesem Zweck hat Taproot eine Lösung vorgeschlagen, die für Skripte mit einer begrenzten Anzahl von Unterzeichnern in zwei Teile unterteilt werden kann:
Der erste Teil ist die Mehrfachsignatur, bei der sich alle Unterzeichner auf ein bestimmtes Ausgabeergebnis einigen, das als „gemeinsame Ausgaben“ bezeichnet wird.
Der zweite Teil heißt „nicht kollaborative Ausgaben“ und kann eine sehr komplexe Skriptstruktur haben.
Diese beiden Teile stehen in einer „oder“-Beziehung.
Wie in Abbildung 3 dargestellt, handelt es sich bei Skript 3 um eine 2-aus-2-Mehrfachsignatur, für deren Gültigkeit sowohl die Unterschrift von Alice als auch von Bob erforderlich ist. Es handelt sich um eine „gemeinsame Ausgabe“, während es sich bei Skript 1 und 2 um „nicht gemeinschaftliche Ausgaben“ handelt.
Sowohl „gemeinsame Ausgaben“ als auch „nicht gemeinschaftliche Ausgaben“ können diesen Output ausgeben, darunter:
Übernehmen Sie für das Skript „Nicht kollaborative Ausgaben“ die obige MAST-Methode und verwenden Sie MerkleRoot, um die Merkle-Baumwurzel darzustellen.
Für „kollaborative Ausgaben“-Skripte wird ein auf Schnoor-Signaturen basierender Multisignaturalgorithmus übernommen. Angenommen, Pa und Pb repräsentieren die öffentlichen Schlüssel von Alice bzw. Bob und Da und Db repräsentieren die privaten Schlüssel von Alice bzw. Bob. Daher ist der aggregierte öffentliche Schlüssel P=Pa+Pb und der entsprechende private Schlüssel ist Da+Db.
„Kooperative Ausgaben“ und „nicht kooperative Ausgaben“ werden in der Form P2PKH zusammengefasst. Der öffentliche Schlüssel lautet: PP+H(P||MerkleRoot)G; der entsprechende private Schlüssel ist Da+Db+H(P| |MerkleRoot ).
Wenn Alice und Bob „gemeinsame Ausgaben“ vereinbaren, verwenden sie Da+Db+H(P||MerkleRoot). Alles, was sie brauchen, ist, dass einer von ihnen H(P||MerkleRoot) zu seinem privaten Schlüssel hinzufügt.
In der Kette verhält sich dies wie eine P2PKH-Transaktion mit einem öffentlichen Schlüssel und einem entsprechenden privaten Schlüssel, ohne dass der zugrunde liegende MAST offengelegt werden muss.
3. Unsere vollständig dezentrale BTC-Layer2-Lösung:
3.1 BTC-Light-Knoten + Signaturvertrag mit verteiltem Schwellenwert
In dieser Lösung werden n (n können alle Validatoren auf BEVM sein) feste Validatoren ausgewählt, um den aggregierten Verwahrungsvertrag auf der BTC-Kette mit verteilten Schwellenwertsignaturen abzuschließen.
Der blockerzeugende private Schlüssel jedes Validators in BEVM-Schicht 2 leitet auch einen Teil des aggregierten privaten Schlüssels der Schwellenwertsignatur von BTC ab. Die privaten Schwellenwertschlüssel von n Validatoren werden in der aggregierten Signaturfotoadresse von BTC kombiniert. Der maximale Wertebereich von n kann 1000 oder mehr betragen.
Wenn Benutzer A BTC mit BEVM verketten möchte, muss der Benutzer nur BTC an den Bitcoin-Aggregation-Custody-Vertrag senden, und der Benutzer kann BTC auf BEVM-Schicht 2 empfangen.
Wenn Benutzer A einen Abhebungsvorgang durchführt, benötigt er entsprechend nur m der n Verifizierungsknoten, um eine aggregierte Signatur zu bilden, um die Interoperation des verteilten Schwellenwertsignaturvertrags automatisch abzuschließen, und die Übertragung vom Verwahrungsvertrag an Benutzer A kann auf Bitcoin abgeschlossen werden. Nach Abschluss wird BTC auf BEVM vernichtet.
3.2 Implementieren Sie BTC als native Gasgebühr und EVM-kompatible Layer2
1) EVM-Prinzip
Die Ethereum Virtual Machine ist die Laufzeitumgebung für Ethereum Smart Contracts. Es handelt sich nicht nur um eine Sandbox, sondern es ist sogar völlig isoliert.
Das bedeutet, dass der in der EVM ausgeführte Code keinen Zugriff auf das Netzwerk, das Dateisystem und andere Prozesse hat. Sogar der Zugriff zwischen Smart Contracts ist begrenzt.
Die unterste Ebene von Ethereum unterstützt die Ausführung und den Aufruf von Verträgen über das EVM-Modul. Beim Aufruf wird der Vertragscode entsprechend der Vertragsadresse abgerufen und zur Ausführung in die EVM geladen. Normalerweise besteht der Entwicklungsprozess von Smart Contracts darin, mithilfe von Solidität Logikcode zu schreiben, ihn dann über einen Compiler in Bytecode zu kompilieren und ihn schließlich auf Ethereum zu veröffentlichen.
2) Hauptteil von EVM
3) EVM-Code
EVM-Code ist der Code der Ethereum Virtual Machine, der sich auf den Code der Programmiersprache bezieht, die Ethereum enthalten kann. Der mit einem Konto verknüpfte EVM-Code wird jedes Mal ausgeführt, wenn eine Nachricht an dieses Konto gesendet wird, und kann den Speicher lesen/schreiben und selbst Nachrichten senden.
4) Maschinenzustand
Der Maschinenstatus ist der Ort, an dem der EVM-Code ausgeführt wird, einschließlich Programmzähler, Stapel und Speicher.
5) Lagerung
Speicher ist ein lesbarer, beschreibbarer und veränderbarer persistenter Speicherplatz. Er ist auch der Ort, an dem jeder Vertrag Daten dauerhaft speichert. Der Speicher ist eine riesige Karte mit insgesamt 2256 Slots, jeder Slot hat 32 Bytes.
6) Verwenden Sie BTC als Gasgebühr
Lassen Sie die vom Bitcoin-Netzwerk übertragenen BTC als Berechnungswährung für die Gasgebühr für die Transaktionsausführung auf dem EVM verwenden.
