Heute wurde in der Firmen-Chatgruppe ein Dienstplan gepostet: Wer ist für das Aufschließen verantwortlich, ab wann muss man vor Ort sein und wie ist die Telefonnummer – alles steht ganz klar und unmissverständlich da.
Anfangs dachte ich noch, die Organisation sei ziemlich geregelt. Dann kam mir aber der Gedanke: Wenn das kein gewöhnlicher Dienst ist, sondern eine Liste darüber, „wer den Schlüssel zum Tresor verwahrt“, dann ist eine vorherige Veröffentlichung nicht unbedingt Transparenz, sondern eher so, als würde man Leuten aktiv Zielscheiben hinlegen.
Sodass ich, nachdem ich den Ledger überprüft hatte, wieder in das @Dusk Whitepaper geschaut habe – in ein Design, das ich vorher nicht wirklich auseinander genommen hatte: Proof-of-Blind Bid.
Viele PoS-Ketten diskutieren nur, wer am meisten staked, und wer am ehesten einen Block produzieren kann. Dusk fragt aber noch eine Schicht tiefer: Wenn der nächste Blockproduzent vorher sichtbar gemacht wird – wird er dann zuerst angegriffen, bestochen oder sogar direkt vom Netz getrennt?
Die Lösung ist ziemlich interessant. Die Bietungen der Teilnehmer fließen in einen Merkle Tree. Darin steht nicht die offene Wahrheit, sondern ein Commitment auf die gestakete Menge von $DUSK sowie die zugehörigen Daten.
Kandidaten können mit Zero-Knowledge Proofs belegen, dass „mein Angebot gültig ist und ich die Bedingungen erfülle“, ohne dabei im Voraus Identität oder die konkrete Staking-Höhe offenlegen zu müssen.
Der Generator, der die Ziehbedingung erfüllt, schlägt anschließend den Block vor. Danach führt das Provisioner-Komitee, das deterministisch per Losziehung ausgewählt wird, die Reduction und Agreement aus – damit sind Validierung und finale Bestätigung erledigt.
In einfachen Worten: Die Person, die die Antwort schreibt, versteckt zuerst die Sitznummer; die Person, die korrigiert, zieht danach separat – so dass Angreifer nicht frühzeitig vor Ort „lauern“ können.
Genau das finde ich auch an #dusk spannend: Privatsphäre dient hier nicht nur für Zahlungen, sondern wird in das Sicherheitsdesign der Konsens-Teilnehmer eingebaut.
Es sorgt nicht dafür, dass alles für immer verborgen bleibt, sondern senkt die Wahrscheinlichkeit, dass Schlüsselrollen zu früh festgenagelt werden.
Natürlich muss man den Wecker noch mit kaltem Wasser füllen: Versteckte Biet-Informationen bedeuten nicht, dass das Netzwerk auf absolut anonyme Weise funktioniert. Man muss IPs der Nodes, die Deploy-Methoden und die Konzentration des Stakings weiterhin betrachten. PoBB löst Risiken wie „Blockproduzenten werden zu früh offengelegt“, ist aber kein Allheilmittel.
Aber im Vergleich dazu, nur TPS als Poster zu drucken, habe ich viel lieber den Blick auf solche Marketing-unfreundlichen und im Angriffsfall möglicherweise lebensrettenden Details.
Welche Art Risiko hältst du bei einer PoS-Blockchain für die wichtigste, die zuerst abgewehrt werden muss?
$BTC
$ETH
Anfangs dachte ich noch, die Organisation sei ziemlich geregelt. Dann kam mir aber der Gedanke: Wenn das kein gewöhnlicher Dienst ist, sondern eine Liste darüber, „wer den Schlüssel zum Tresor verwahrt“, dann ist eine vorherige Veröffentlichung nicht unbedingt Transparenz, sondern eher so, als würde man Leuten aktiv Zielscheiben hinlegen.
Sodass ich, nachdem ich den Ledger überprüft hatte, wieder in das @Dusk Whitepaper geschaut habe – in ein Design, das ich vorher nicht wirklich auseinander genommen hatte: Proof-of-Blind Bid.
Viele PoS-Ketten diskutieren nur, wer am meisten staked, und wer am ehesten einen Block produzieren kann. Dusk fragt aber noch eine Schicht tiefer: Wenn der nächste Blockproduzent vorher sichtbar gemacht wird – wird er dann zuerst angegriffen, bestochen oder sogar direkt vom Netz getrennt?
Die Lösung ist ziemlich interessant. Die Bietungen der Teilnehmer fließen in einen Merkle Tree. Darin steht nicht die offene Wahrheit, sondern ein Commitment auf die gestakete Menge von $DUSK sowie die zugehörigen Daten.
Kandidaten können mit Zero-Knowledge Proofs belegen, dass „mein Angebot gültig ist und ich die Bedingungen erfülle“, ohne dabei im Voraus Identität oder die konkrete Staking-Höhe offenlegen zu müssen.
Der Generator, der die Ziehbedingung erfüllt, schlägt anschließend den Block vor. Danach führt das Provisioner-Komitee, das deterministisch per Losziehung ausgewählt wird, die Reduction und Agreement aus – damit sind Validierung und finale Bestätigung erledigt.
In einfachen Worten: Die Person, die die Antwort schreibt, versteckt zuerst die Sitznummer; die Person, die korrigiert, zieht danach separat – so dass Angreifer nicht frühzeitig vor Ort „lauern“ können.
Genau das finde ich auch an #dusk spannend: Privatsphäre dient hier nicht nur für Zahlungen, sondern wird in das Sicherheitsdesign der Konsens-Teilnehmer eingebaut.
Es sorgt nicht dafür, dass alles für immer verborgen bleibt, sondern senkt die Wahrscheinlichkeit, dass Schlüsselrollen zu früh festgenagelt werden.
Natürlich muss man den Wecker noch mit kaltem Wasser füllen: Versteckte Biet-Informationen bedeuten nicht, dass das Netzwerk auf absolut anonyme Weise funktioniert. Man muss IPs der Nodes, die Deploy-Methoden und die Konzentration des Stakings weiterhin betrachten. PoBB löst Risiken wie „Blockproduzenten werden zu früh offengelegt“, ist aber kein Allheilmittel.
Aber im Vergleich dazu, nur TPS als Poster zu drucken, habe ich viel lieber den Blick auf solche Marketing-unfreundlichen und im Angriffsfall möglicherweise lebensrettenden Details.
Welche Art Risiko hältst du bei einer PoS-Blockchain für die wichtigste, die zuerst abgewehrt werden muss?
$BTC
$ETH
出块者被提前攻击
25%
少数节点控制共识
38%
区块确认速度太慢
37%
8 Stimmen • Abstimmung beendet