ASICBoost

Bei ähnlichen Bestellungen lassen sich gemeinsame Angaben einmal vorbereiten. Jede Bestellung muss trotzdem einzeln abgeschlossen werden. So kann man sich die Grundidee von ASICBoost vorstellen. Timo Hanke beschrieb sie 2016 unter Hinweis auf die Zusammenarbeit mit Sergio Demian Lerner. Ein ASIC ist ein Chip für eine bestimmte Rechenaufgabe; eine andere Arbeitsorganisation vermeidet Wiederholungen. Weder SHA-256, die verwendete Hashfunktion, noch die Bitcoin-Regeln ändern sich. Der endgültige doppelte Hash des Headers darf weiterhin höchstens dem Zielwert entsprechen, und der gesamte Block muss gültig sein. [1]

Ein Byte ist eine Einheit für die Größe digitaler Daten. Der Header fasst wichtige Blockdaten auf 80 Bytes zusammen. Im ersten Hashdurchlauf werden zunächst 64 Bytes und anschließend die übrigen 16 samt vorgeschriebener Auffüllung verarbeitet. Die Merkle root, der gemeinsame Fingerabdruck der Transaktionen, reicht über diese Grenze: Ihre letzten 4 Bytes liegen im zweiten Teil. Dort stehen auch Zeit, bits als kompakte Darstellung des Mining-Ziels und nonce, der zwischen Versuchen veränderte Zähler. Welche Felder geändert werden, bestimmt daher, welche Berechnungen sich wiederverwenden lassen. [1]

Hanke nennt geeignete Aufgaben colliding work items. Ihre ersten Headerteile unterscheiden sich und erzeugen unterschiedliche midstate-Werte, also Zwischenzustände der Berechnung. Der Message genannte Teil bleibt dagegen gleich. Für eine gewählte nonce lässt sich deshalb der message schedule teilen: die Hilfswerte zur Verarbeitung des zweiten Teils beim ersten SHA-256. Von den verschiedenen Zwischenzuständen aus wird getrennt weitergerechnet. Das sind weder gleiche endgültige Hashes noch ein Bruch der Hashfunktion. „Kollision“ meint hier die Übereinstimmung eines ausgewählten Eingabeteils; die ersten Headerteile unterscheiden sich. [1]

Sergio Demian Lerner unterscheidet overt und covert ASICBoost. Overt verändert erlaubte Bits in nVersion, dem Versionsfeld des Headers. Dabei muss keine teilweise Übereinstimmung der Merkle root gesucht werden. Covert sucht sie dagegen: Die letzten 4 Bytes der Merkle root bleiben gleich, ihr erster Teil ändert sich. Dazu können zulässige Transaktionsdaten oder die Transaktionsreihenfolge verändert werden. Die Abhängigkeiten zwischen Transaktionen müssen erhalten bleiben, und die gespeicherten Fingerabdrücke müssen weiter zu den Blockdaten passen. Unterschiedliche Headerversionen allein belegen weder eine konkrete Energieersparnis noch die Identität des Betreibers. [2]

Ein Pool koordiniert die Arbeit von Minern. Sein Server ist der Computerdienst, mit dem das Gerät kommuniziert; er nimmt Ergebnisse nach den vereinbarten Bedingungen an. Peters Gerät darf den Header nicht beliebig ändern. Das Dokument mit der Kennnummer BIP310 beschreibt die Aushandlung über mining.configure: version-rolling.mask bezeichnet veränderbare Bits; die Antwort enthält die Schnittmenge der Möglichkeiten von Miner und Server. Die Maske zeigt erlaubte Positionen, verspricht aber keine Mehrleistung. Die Bedingung version_bits & ~last_mask == 0 verlangt, dass übermittelte Bits innerhalb der zuletzt gültigen Maske liegen. Eine Nachricht mining.set_version_mask gilt sofort, nicht erst ab der nächsten Aufgabe. Die Firmware, also die Steuersoftware des Geräts, muss diese Vereinbarung einhalten. [3]

BIP320 schlägt 16 allgemeine nVersion-Bits vor; BIP323 beschreibt als vorgeschlagener Ersatz 24 Bits. Bei dieser redaktionellen Prüfung haben beide Dokumente den Status Draft. Das bedeutet weder automatisch, dass nichts implementiert ist, noch dass jeder Pool die Funktion unterstützt. Der Text beschreibt die beabsichtigte Verwendung des Felds; eine konkrete Verbindung hängt von ihrer tatsächlichen Maske und Software ab. Aus einer BIP-Nummer kann Peter deshalb keine Änderungsbefugnis seines Geräts und keine automatische Änderung der Netzwerkregeln ableiten. [4] [5]

Hankes Modell beschreibt die Ersparnis mit x × (n − 1) / n. Dabei ist x der gemeinsam nutzbare Rechenanteil und n die Zahl geeigneter Aufgaben. Mit x = 25% und n = 4 ergeben sich 18.75%. Gemeinsame Vorarbeit wird für die Aufgaben zusammen erledigt statt ständig wiederholt. Das Ergebnis gilt für dieses Rechenmodell, nicht automatisch für eine gleich große Watt-Ersparnis jedes Geräts. Andere Schaltungen und Betriebsbedingungen beeinflussen den Verbrauch ebenfalls. Der Wert darf daher nicht ungeprüft als Leistungs- oder Ertragssteigerung übernommen werden. [1]

Peter prüft zunächst Chip, Firmware und Zusammenarbeit mit dem Pool. Danach kontrolliert er, ob der Pool die Arbeit annimmt, und misst das ganze Gerät unter vergleichbaren Bedingungen. J/TH steht für Joule pro Terahash: die Energie für eine Billion Hashversuche. Beim Vergleich müssen dieselben Geräteteile und derselbe Messzeitraum erfasst werden. Der Name ASICBoost ersetzt diese Messung nicht. Er steht auch nicht für Übertakten, also eine erhöhte Betriebsfrequenz, und garantiert weder einen Blockfund noch Gewinn. Bestimmte Arbeit lässt sich damit sparsamer erledigen, wenn die gesamte eingesetzte Technik zusammenspielt. [1] [3]