Anna-汤圆

Mit Dusk setzt man auf den Schatz—vielleicht sind es diese zwei Worte „Privatsphäre“ gar nicht

In den letzten Tagen habe ich mir den ganzen Technik‑Baukasten von Dusk noch einmal auseinandergelegt und neu angeschaut, und plötzlich wurde mir klar, dass ich seine Ausrichtung bisher völlig falsch verstanden habe @Dusk
//
Am Anfang dachte ich, Dusk sei einfach nur wieder eine weitere Privacy‑Coin: Beträge verstecken, Adressen verstecken, Handelspartner verstecken—ähnlich wie bei Monero. Aber erst als ich die Puzzlestücke wie XSC und CITP zusammengelegt habe, habe ich gesehen, dass Dusk tatsächlich eine komplette Ausführungskette für tokenisierte Wertpapiere/RWA aufbaut: von der Tokenisierung der Assets auf die Kette, über die regelkonforme Offenlegung bis hin zur Ausführung der Trades. Jede Station zielt darauf, in Richtung „regulatorisch akzeptierbar“ zu gehen—nicht darauf, mit aller Kraft „absolute Anonymität“ zu erreichen #
//
Am spannendsten finde ich den Begriff „vertrauliche Interoperabilität“. Privatsphäre ist keine einsame Insel. Die Daten, die man on‑chain versteckt, müssen in der Lage sein, mit externen traditionellen Finanzsystemen und anderen Ketten zu kommunizieren—und dabei darf im Kommunikationsprozess kein Geheimnis nach außen durchsickern. Das ist viel schwerer als nur „etwas zu verstecken“: Verstecken ist leicht. Die eigentliche Kunst ist, dass es sich trotzdem überprüfen lässt und sich mit externen Systemen verbinden lässt.
//
Ich habe für mich so darüber nachgedacht: Was Dusk im Moment für eine echte, großflächige Übernahme durch Institutionen noch fehlt, ist nicht die Privatsphäre‑Technik selbst, sondern die „Umgebung“ darum herum—zuverlässige Oracles, eine Toolchain, die durch Audits kommt, und Schnittstellen, die sich an Standards des traditionellen Finanzwesens andocken lassen. Das sind die letzten Meilensteine dafür, ob „regulatorisch geeignete Institutionen“ es wirklich einsetzen können #dusk
//
Nachdem ich das verstanden habe, hat sich mein Bild von Dusk komplett verändert. Dusk setzt nicht auf „Privatsphäre“ an sich, sondern darauf, dass „Privatsphäre als Eintrittskarte für reguliert gehandeltes, tokenisiertes Asset“ funktioniert—das ist ein komplett anderes Spiel als bei traditionellen Privacy‑Coins: Das eine will, dass du völlig verschwindest, das andere will, dass du deine Privatsphäre behältst, während du zugleich unter Regulierung stehst
//
Eine Frage: Ist die Kernpositionierung von Dusk näher an was anderem als an diesem? $DUSK

我把TermMax V2的"聪明"藏在哪扒出来了 @TermMax

这两天我把TermMax V2的App翻了个遍，说实话一开始没觉得有多特别，直到我发现自己少做了一件以前每次借贷都要做的事——比价
//
以前我用DeFi借贷，脑子里永远绷着一根弦：这个订单利率划算吗？隔壁那个池子是不是更好？切来切去，自己活生生变成了个人工撮合器。V2这次直接把这一层麻烦拿走了，Curator Range Orders、Limit Orders这些原本分得清清楚楚的订单类型，被塞进了同一个执行层，我打开App，看到的就是一个Quote，背后那堆比价的活协议已经替我干完了
//
我最有感触的是跨链这块。以前想比较不同链上的利率机会，我得开好几个页面来回切，现在官方讲的是"one app, every chain, every order"，多条链的市场直接摆在一起，协议还会把不同来源的订单拼成一笔交易，帮我找最优路径，我不用自己一单一单去凑
//
我自己琢磨了一下，这次升级真正值钱的不是界面好不好看，是把"我要花时间搜信息"和"我要自己执行比价"这两件麻烦事，从我身上搬到了协议那一层。这已经不太像一个传统意义上的借贷池了，更像是一个链上利率路由器——你要的从来不是哪个池子，是哪个价格最好、执行最顺
Fixed-rate Liquidity Router，我觉得这个说法比Lending Protocol更贴近它现在的样子#TermMax
//
问一句：TermMax V2真正省下的是什么成本？

In den letzten zwei Tagen habe ich die App von TermMax V2 einmal durchprobiert – und je mehr ich sie nutze, desto mehr habe ich das Gefühl, dass viele den Kern dieser Upgrades missverstehen. @TermMax
//
Die meisten denken vielleicht, V2 wäre im Wesentlichen nur optisch hübscher und hätte ein paar zusätzliche Order-Typen. Aber ich habe mich mal durch die Details gegraben: Die eigentlichen Änderungen stecken an Stellen, die man nicht sofort sieht. Es wurden zuvor getrennte Order-Typen wie Curator Range Orders und Limit Orders in dieselbe Ausführungsschicht vereinheitlicht. Früher musstest du selbst herausfinden, welcher Order-Typ in der jeweiligen Situation passt – jetzt werden diese Unterschiede von dem Protokoll „aufgegessen“, und vor dir liegt nur noch ein einheitlicher Ausführungs-Entry.
//
Am wichtigsten finde ich das Design von „Best Execution“. Früher, bei DeFi-Krediten, musstest du selbst in einzelnen Orderbüchern vergleichen und ausrechnen, welcher Zinssatz wirklich besser ist. Ganz offen: Du bist im Grunde selbst der Vermittler („Matcher“). V2 macht genau diesen Schritt direkt überflüssig. Du öffnest die App und siehst ein Quote – das Protokoll hat im Hintergrund bereits einmal alles gegeneinander abgewogen. Das klingt simpel, aber eigentlich verlagert es die „Kosten für Informationssuche“ vom Nutzer auf die Protokollschicht.
//
Wenn man noch weiter schaut, wird auch der Teil zum Cross-Chain-Marktplatz interessant.
Offiziell heißt es jetzt: „one app, every chain, every order“ – Märkte über mehrere Chains werden direkt zusammen angezeigt. Du musst nicht mehrere Seiten öffnen und hin- und herwechseln, um sich Chancen auf unterschiedlichen Chains bei den Zinssätzen anzusehen. Das Protokoll kombiniert außerdem Orders aus unterschiedlichen Quellen zu einer einzigen Transaktion und sucht dir die optimalen Liquiditätswege, statt dich dazu zu zwingen, jede einzelne Order mühsam selbst zusammenzustellen.
//
Meine Interpretation ist: Wenn man all das zusammensetzt, wirkt TermMax immer weniger wie ein klassischer „Kreditpool“, sondern eher wie ein On-Chain-Zins-Router. Was der Nutzer will, ist schließlich nie „welcher Pool“, sondern „welcher Preis ist am besten und wie reibungslos wird ausgeführt“. Mit diesem Upgrade scheint sich V2 genau in diese Richtung zu bewegen. #TermMax
Fixed-rate Liquidity Router, dieses Branding trifft das vielleicht sogar genauer als „Lending Protocol“.

Was sind die Kernänderungen von TermMax V2?

这两天我翻了翻Dusk的隐形地址设计，发现我以前想的太简单了——光藏住金额根本不够，链上分析真正盯的是地址关联性，同一个地址反复收款、反复出现，人家照样能拼出你的资金画像

//
先说说我理解的，这个一次性地址是怎么造出来的
Dusk用的是ECDH式的密钥协商，我理解就是付款方拿着收款方公开的地址信息，配合一个随机数，通过椭圆曲线运算，派生出一个全新的一次性接收地址，每笔交易都长得不一样。收款方的"主地址"从头到尾都没在链上直接露过面，我作为外人看到的永远是一堆看似互不相干的新地址，压根拼不出这些地址背后其实是同一个人

//
那我当时第一反应就是，那钱收款方到底怎么找回来
这就得靠view key，也就是视图密钥。收款方拿着这把key，去扫描链上所有输出，用密钥学的方式识别出哪些note是派生给自己的——我作为外人做不到这一步，因为我没有对应的私钥材料，但收款方自己能算出来。我觉得这个设计挺巧的一点是，view key还能单独授权给第三方（比如审计方）做只读扫描，不用交出真正能动用资金的花费权限

//
我拿这套东西跟经典的stealth address方案（比如CryptoNote那套）比了一下，发现Dusk这套不是孤立存在的，是要跟整个zk账本咬合起来的。一次性地址派生出来之后，对应的资产要打包进一个note，note里带着价值承诺，花掉的时候还得生成对应的nullifier防双花
我理解地址隐藏解决的是"钱去哪了看不出来"，承诺和nullifier解决的是"钱有多少、花没花"这两件事看不出来，三层东西得对齐咬合在一起，隐私才算完整，少一环都会露馅

@Dusk #dusk $DUSK @Dusk
view key的作用是什么？

🌙 Siebter-Nacht-Special | Tuan Yuan lädt dich ein, den Siebter-Nacht-Abend gemeinsam zu verbringen

Die 27. Runde des „Scherli-Zi“-Spiels steht kurz bevor! 🔥

📅 Ab 19. August um 12:00 Uhr offiziell gestartet
💰 Die Community hat 100.000 Scherli-Zi als Preispool-Bonus eingezahlt
🎁 Die Adresse, die an dieser Runde teilnimmt, erhält zusätzlich einen 20-Sch‘erli-Zi-Wohltaten-Airdrop
⏰ Gültige Zeit zum Abholen: bis 20. August 22:00 Uhr

Heute Abend Live-Stream, Tuan Yuan begleitet euch durch einen ganz besonderen Siebter-Nacht-Abend ❤️

Dieser Live-Stream dreht sich um den Siebter-Nacht-Tag × das Scherli-Zi-Spiel. Wie spielt man das Spiel, wie bekommt man die Vorteile,

und es gibt weiterhin während des Live-Streams Airdrop-Vorteile!

Egal, ob du ein alter Freund bist oder gerade neu auf dem Platz dazugekommen—komm vorbei und spiel mit.

Tonight sehen wir uns im Live-Stream @Anna-汤圆 !
🎁 Airdrops ohne Ende
🔥 Spiele ohne Ende
🌙 Lasst uns den Siebter-Nacht-Abend zusammen spielen!

Spiel-Einstieg: 105906.xyz

#舍利子 #MEME #空投

Wenn man @TermMax s FT, XT und GT als drei separate Tokens versteht, finde ich, dass man sich sehr leicht verheddert.
Ich würde die Frage stattdessen eher umdrehen:
Bei einem DeFi-Kredit – was steckt eigentlich wirklich drin?
Im Grunde sind es ein paar Dinge: Wie viel man in der Zukunft zurückzahlen muss, der Zinswert in diesem Kredit und welche Sicherheiten der Kreditnehmer bereitstellt sowie wie viel Risiko die gesamte Position trägt.
Was TermMax macht, ist, diese Bestandteile auseinanderzunehmen.
Zuerst schauen wir uns FT an.
FT ist im Kern so etwas wie eine Nullkuponanleihe: mit Abschlag gekauft, und bei Fälligkeit zum Nennwert ausgezahlt. Wenn du zum Beispiel 90 USDC ausgibst, um einen FT zu kaufen, der bei Fälligkeit 100 USDC auszahlen kann, dann kaufst du im Grunde einen zukünftigen, fest bestimmten Cashflow.
Als Nächstes: XT.
Es ist nicht einfach ein „Points-Token“, sondern ein Bestandteil des Zinswerts innerhalb der Kreditstruktur. In TermMax bilden FT und XT gemeinsam ein Wertverhältnis einer Schuld ab; das zentrale Verhältnis kann man so verstehen:
1 FT + 1 XT = 1 debt token
Und zuletzt: GT.
GT ist noch spannender: Es ist kein gewöhnlicher ERC-20, sondern ein ERC-721 NFT.
Man kann es als einen „Positions-Container“ begreifen, der die Sicherheiten und die Schulden festhält und zugleich den Status der gesamten Leverage-Position abbildet. Früher musste man bei der Verwaltung einer komplexen Leverage-Position eventuell sehr viele Informationen handhaben; jetzt kann man die komplette Position in ein NFT packen.
Wenn man also die drei Dinge zusammen betrachtet, wird es klarer:
FT beantwortet, „wie viel in der Zukunft ausgezahlt werden muss“.
XT trägt „den Zinswert in dieser Kreditaufnahme“.
GT löst „wie Sicherheiten und die gesamte Kreditposition verwaltet werden“.
Das ist auch der Teil, den ich an TermMax besonders untersuchenswert finde.
Es macht möglicherweise nicht nur einen festen Zinssatz, sondern zerlegt einen traditionellen Kredit weiter in verbriefte Cashflows, in den Zinswert – und in eine NFT-Position, die verwaltet und übertragen werden kann.
Ganz einfach: einen Kredit „auseinandernehmen“.
Aber das Problem ist:
Wenn man Token so fein zerlegt, wer bestimmt dann die Preise für FT, XT und GT?
Wie sollen Tokens mit unterschiedlicher Laufzeit, unterschiedlichem Zins und unterschiedlichem Risiko zu einem sinnvollen Preis führen?
Diese Frage ist vielleicht sogar wichtiger zu erforschen als die Frage, wie man Tokens aufteilt.
#termMax
Wem entspricht TermMax' FT im Kern am ehesten?

Ich habe mir diese Tage noch einmal Phoenix’ Transaktionsstruktur genauer angesehen. Diesmal habe ich eine einzelne Transaktion einfach aufgesplittet, um herauszufinden, was man on-chain erkennen kann und was nicht.
━━━━━━━━━━━━━━
▎note: Was steckt in dem Eintrag?
Phoenix ist ein UTXO-Modell. Jede einzelne Einheit von Vermögenswerten heißt auf der Chain eine „note“. In so einer note werden drei Dinge verpackt: ein Commitment auf den Betrag (keine Klartext-Zahl, sondern ein verschlüsselter Commitment-Wert), ein blinding factor (vereinfacht: ein zufälliger Salt, der zum Commitment hinzugefügt wird, damit niemand durch Kollisionen auf den Betrag schließen kann) und eine einmalige Zufallszahl, die dafür sorgt, dass jede note eindeutig ist und nicht mit anderen notes kollidiert.
Diese drei Dinge zusammen bedeuten: On-chain sieht man im Grunde nur jede Menge verschlüsselte Daten. Wie viel konkret überwiesen wurde und wie viel diese note tatsächlich wert ist, kann ein Außenstehender nicht herausfinden. Das Netzwerk kann aber dennoch verifizieren, dass die Summe der Commitments für Ein- und Ausgänge ausbalanciert ist, ohne irgend eine konkrete Zahl zu entschlüsseln.
━━━━━━━━━━━━━━
▎Schutz vor Double-Spending durch nullifier
Das Design finde ich ziemlich genial: Es verhindert Double-Spending nicht dadurch, dass man „alte notes löscht“, sondern dadurch, dass man ein Konsumations-„Nachweis“-Token veröffentlicht, das sich nicht auf die ursprüngliche note zurückführen lässt.
Wenn man eine note ausgibt, wird ein dazugehöriger nullifier erzeugt. Dieses Ding wird deterministisch berechnet. Für Außenstehende ist es jedoch unmöglich, daraus direkt abzuleiten, zu welcher note es gehört. Das Netzwerk muss nur darauf achten: „Ist dieser nullifier schon einmal aufgetaucht?“ Wenn ja, dann heißt das, dass die dazugehörige note bereits ausgegeben wurde. Wenn man versucht, dieselbe note ein zweites Mal auszugeben, wird derselbe nullifier erneut erzeugt – und prallt direkt mit dem bereits vorhandenen Eintrag zusammen. Das System lehnt die Transaktion sofort ab.
Im gesamten Prozess wird nicht offengelegt, „wer etwas tut“ oder „was genau ausgegeben wird“ – alles wird über Kollisionsprüfungen geregelt.
━━━━━━━━━━━━━━
▎Poseidon-Hash: Das Fundament für den gesamten Privacy-Status
Der Privacy-Status muss in einem Merkle-Baum gespeichert werden. Dafür nutzt man Beweise für die Zugehörigkeit von Mitgliedern (also den Nachweis: „Diese note existiert tatsächlich im Statusbaum“).
Wenn man eine normale Hash-Funktion in einen zk-Schaltkreis einbaut, ist der Aufwand enorm. Poseidon ist eine Hash-Funktion, die speziell für zk-freundliche Systeme entwickelt wurde. Ihr Aufbau passt besser zum Beweissystem, wodurch die Kosten für Hash-Berechnungen in den Schaltkreisen deutlich sinken. Ohne so einen zk-freundlichen Hash wäre die Generierung der Beweise für den Privacy-Statusbaum so langsam, dass sie praktisch nicht nutzbar wäre.
@Dusk $DUSK #dusk
In einer Phoenix-Transaktion: Welche Mechanismen verhindern, dass versteckte Assets doppelt ausgegeben werden?

Ein in DeFi leicht zu übersehendes Problem: Variable Zinssätze sind ebenfalls ein Risiko
Neulich habe ich mir @TermMax angesehen und bin auf eine ziemlich interessante Frage gestoßen.
Wenn wir normalerweise bei Aave oder Morpho USDC bzw. ETH leihen, ist unsere erste Reaktion meist, sich auf den Beleihungssatz, den LTV und die Liquidationslinie zu konzentrieren.
Aber es gibt etwas, das sich eigentlich ständig ändert – der Zinssatz für geliehenes Geld.
Wenn du heute Geld leihst, wirkt eine Verzinsung von 4 % vielleicht angenehm. Doch was ist in 30 Tagen? Wenn sich der Markt ändert und die Zinsen auf 7 %, 8 % steigen, ist der ursprünglich gut kalkulierte Spielraum für Gewinne vielleicht sofort dahin.
Gerade bei Strategien mit Hebel oder Arbitrage macht einem das wirklich zu schaffen.
Denn wie viel man verdient, ist das eine – wie viel man für das geliehene Geld zurückzahlen muss, das andere.
Deshalb glaube ich mittlerweile immer mehr, dass der Sinn von Festzinsen nicht einfach darin liegt, dass der Zinssatz „immer niedriger“ ist, sondern dass ich zumindest weiß:
Bis wann ich dieses Geld bekomme – und wie viel ich dafür insgesamt zahlen muss.
Der spannende Punkt bei TermMax ist genau hier.
Es geht nicht nur darum, den variablen Zinssatz in einen festen zu verwandeln, sondern auch die Maturity (Laufzeit) mit in den Markt einzubauen: Durch Debt Token, Collateral Token und Maturity wird ein terminiertes Marktmodell geschaffen.
Kurz gesagt: DeFi-Leihen und -Kredite wird ein früher oft ignorierter Faktor hinzugefügt – die Zeit.
Früher war es für viele eher die Norm „jederzeit ausleihen und zurückzahlen“, bei der der Zinssatz ständig schwankt. TermMax versucht hingegen, aus einer Kreditaufnahme eine Finanzierung mit klarer Laufzeit und klaren Kosten zu machen.
Ich finde diesen Ansatz ziemlich interessant.
Denn in DeFi diskutieren wir ständig über Rendite, Liquidation und Hebel – aber viel zu selten ernsthaft über Folgendes:
„Kann ich diese Verbindlichkeit so planen, dass ich im Voraus weiß, wie viel sie mich am Ende kosten wird – noch bevor sie fällig wird?“
Das ist vielleicht genau der echte Wert von Festzinsen.
#TermMax
Was ist der größte Wert von TermMax bei Festzinsen?

PLONK: Wie man auf der Chain Berechnungen „beweisbar“, statt „reproduzierbar“ macht
In den letzten Tagen schaue ich mir das PLONK-Beweissystem genauer an. Je mehr ich es verstehe, desto mehr habe ich das Gefühl, dass die Blockchain-Validierung diese Logik komplett neu schreibt.
Zuerst ein naives Problem: Wie bestätigt man auf der Chain, dass eine Berechnung korrekt ist?
Der naheliegendste Ansatz ist: „nochmal alles neu berechnen“ – jeder Knoten führt dieselbe Berechnung aus, und wenn die Ergebnisse übereinstimmen, gilt es.
Das ist zwar dumm, aber funktioniert. Nur steigen die Kosten dann linear mit der Rechenmenge: Je komplexer die Berechnung, desto größer wird der Overhead, weil das ganze Netzwerk sie immer wieder erneut verifizieren muss.
Was PLONK stattdessen macht, ist: Aus „nochmal alles berechnen“ wird „einen Beweis fester Größe für etwas bereitstellen“.
Egal wie komplex die Berechnung ist – die Größe des Beweises, die der Verifizierer prüfen muss, bleibt im Wesentlichen konstant. Der Aufwand wächst kaum mit der Größe der Berechnung an. Das ist keine bloße Optimierung, sondern ein grundlegender Austausch der Kostenstruktur.
━━━━━━━━━━━━━━
Das dahinter steckt: KZG-Polynomverpflichtungen (KZG Polynomial Commitments)
PLONK kodiert die gesamten Randbedingungen des Schaltkreises in mehrere Polynome. Der Beweiser muss dir keine Rechendetails offenlegen – er muss nur beweisen, dass die Werte dieser Polynome an bestimmten Punkten korrekt sind.
Der Verifizierer erhält dann nur ein paar Gruppenoperationen, die sich sehr leicht ausführen lassen. Eine ganze Menge Ausführungstrajektorien wird zu einigen wenigen prägnanten algebraischen Prüfungen verdichtet.
Ein weiterer Schlüsselentwurf ist: Preprocessing.
Die Teile des Schaltkreises, die öffentlich und fest sind, kann man bereits im Voraus offline berechnen, sodass man bei jeder Verifikation nicht wieder von vorn anfangen muss.
Bei der On-Chain-Validierung muss man dann nur noch die leichten Bestandteile verarbeiten, die sich auf diesen konkreten Beweis beziehen. Deshalb kann PLONK „universell und aktualisierbar“ sein: Dasselbe Framework kann Schaltkreise in unterschiedlicher Größe bedienen, ohne dass man jedes Mal die vertrauenswürdige Einrichtung neu durchlaufen muss.
━━━━━━━━━━━━━━
Wenn man es auf Dusk überträgt: Dieses Beweissystem wird direkt über CVM aufgerufen.
Nach der Ausführung eines Privacy-Contracts wird das Ergebnis nicht einfach herausgeworfen, damit andere es erneut verifizieren, sondern es wird direkt ein Beweis ausgegeben – die Ausführung selbst ist dabei der Prozess der Beweisgenerierung.
Das ist der grundlegendste Unterschied zwischen „beweisbar“ und „reproduzierbar“: Das eine setzt darauf, dass alle es nochmal neu berechnen wollen, das andere nutzt Mathematik, sodass man dir vertraut, ohne dass du überhaupt rechnen musst.
@Dusk $DUSK #dusk

In den letzten zwei Tagen habe ich mich durch die Kryptografie-Auswahl für Dusk gearbeitet und eine Entscheidung entdeckt, die extrem leicht übersehen wird: Die Umstellung auf eine andere elliptische Kurve halten die meisten für unwichtig. In Wahrheit zieht das eine ganze Kette nach sich.

//
Zuerst: Warum man nicht einfach das Setup von Bitcoin und Ethereum übernehmen kann.
secp256k1 ist in der Welt der Miner-Wallets die beliebteste Kurve, aber sie ist schlichtweg nicht für zk-Beweise ausgelegt. Das Beweissystem (z. B. die Kurven hinter Plonk wie BN254 oder BLS12-381) begrenzt alle Operationen auf ein bestimmtes Skalarfeld. In der Schaltung müssen Addition und Multiplikation innerhalb dieses Feldes stattfinden. Das Feld von secp256k1 passt überhaupt nicht zu den Feldern dieser Beweissysteme. Wenn man in der Schaltung einen secp256k1-Signatur-Check erzwingen will, muss man „nicht-native“ Operationen simulieren. Das kostet das Tausendfache (oder mehr) dessen, was native Operationen kosten – es geht zwar, aber es ist schlicht unglaublich teuer.

//
Genau dafür ist JubJub gemacht.
JubJub ist eine twisted-Edwards-Kurve. Der entscheidende Punkt ist: ihr Feld lässt sich genau in das Skalarfeld von BLS12-381 einbetten. Das heißt, wenn man in den Plonk-Schaltungen Punktoperationen auf JubJub ausführt, läuft das über native Operationen – der Aufwand sinkt drastisch. Schlüsselgenerierung, Signatur, Verschlüsselung: Diese Dinge passen natürlich zu dem Beweissystem, ohne Umwege.

//
Noch ein Wort zur Ebene „Gruppenabstraktion“: Welche Aufgabe soll sie lösen?
Edwards-Kurven haben in der Regel das Problem, dass ihr Cofaktor nicht 1 ist. Anders gesagt: Zu demselben „logischen Punkt“ können auf der Kurve mehrere verschiedene Byte-Darstellungen gehören. Dass es dabei historisch zu Darstellungsmehrdeutigkeiten und damit zu Schwachstellen kam, ist tatsächlich vorgekommen. Angreifer können Cofaktor-bezogene Untergruppen ausnutzen, Randfälle konstruieren und so die Validierung umgehen. In der Praxis ist die gängige Lösung, noch eine Schicht Gruppenabstraktion über die Kurve zu legen: Die Darstellungsmehrdeutigkeiten werden geglättet, sodass ein Punkt genau eine einzige, normierte Schreibweise hat. Damit wird diese Art von Angriffen von Grund auf blockiert.

//
Wenn man diese Auswahl mit dem in der Miner-Welt beliebtesten secp256k1 vergleicht, wird es sofort klar: Die eine Kurve dient Signatur-Validierungs-Effizienz und Ökosystem-Kompatibilität, die andere dient Kosten innerhalb des Beweissystems und Sicherheitsgrenzen. Sie wurden gar nicht für dasselbe Ziel entworfen. Die Entscheidung, die Kurve zu wechseln, klingt ziemlich technisch und fein, aber sie entscheidet direkt darüber, ob die gesamte zk-Pipeline günstig oder teuer ist – und ob sie sauber ist oder potenzielle Schwachstellen behält.

@Dusk $DUSK #dusk

Warum kann die JubJub-Kurve so gut mit Dusk’ Beweissystem zusammenpassen?

Ich habe in letzter Zeit eine Angewohnheit bei Memes: erst zu schauen, ob es noch etwas gibt, worüber man weiter reden kann.
$niulai kann da echt überzeugen.
Denn dahinter steckt kein bereits abgeschlossenes Internet-Meme, sondern die IP des Films „Niu Lai“.
Danach kann man den Content rund um den Film, Figuren, die Handlung und Community-Memes weiter ausbauen.
Für Memes ist es manchmal wichtiger als am ersten Tag, wie lange sie überhaupt weiter Gesprächsthemen erzeugen können.
#niulai #牛来

Diese Tage habe ich die Konsens-Dokumente von Dusk durchgearbeitet und je mehr ich hinschaue, desto mehr sticht mir ein Detail ins Auge: Bei vielen PoS-Ketten übernehmen Verifizierungs-Validatoren sowohl das Blockproduzieren als auch das Block-Validieren. Vereinfacht gesagt: Eine Person hat zwei Rollen gleichzeitig – nämlich derjenige, der einen Vorschlag macht, und zugleich derjenige, der als Schiedsrichter darüber befindet. Diese Gestaltung birgt von sich aus eine Schwachstelle; für böswilliges Handeln ist der Weg besonders kurz.

//
Dusk trennt diese beiden Aufgaben konsequent voneinander.
Der Konsens heißt SBA (Segregated Byzantine Agreement). Im Kern werden „Blockproduktion“ und „Zeugen-/Witness-Blocks“ als Rollen bereits im Design sauber getrennt. Eine Gruppe von Knoten stellt speziell Kandidatenblöcke zur Abstimmung/als Vorschlag bereit, während eine andere Gruppe Knoten speziell verifiziert, abstimmt und entscheidet, welcher Block auf die Kette kommt.
Die beiden Gruppen haben unterschiedliche Rechte und Pflichten, unterschiedliche Identitäten: Die eine kümmert sich ums Vorschlagen, die andere ums Prüfen. So kann niemand gleichzeitig Spieler und Schiedsrichter in einer Person sein.

//
Auch ein technisches Detail ist dabei ziemlich interessant.
In der Validierungsphase müssen viele Knoten jeweils separat signieren und abstimmen. Wenn jede einzelne Signatur getrennt gesendet und separat verifiziert wird, explodiert der Netzwerkaufwand mit der Anzahl der Knoten. Die Idee von BLS-Aggregationssignaturen ist, dass man aus tausenden unabhängigen Signaturen ein kompaktes Aggregat-Ergebnis macht. Andere Knoten müssen dann nur dieses eine aggregierte Signaturergebnis prüfen – und damit sind die Abstimmungen aller Beteiligten bereits verifiziert. Dadurch sinken die Verifizierungskosten drastisch und die Konsenseffizienz steigt automatisch.

//
Der wirklich wertvolle Teil, wenn man die beiden Schritte trennt, liegt darin, die Einstiegshürde für eine Verschwörung deutlich zu erhöhen.
Wenn Blockproduktion und Blockvalidierung von derselben „Clique“ übernommen werden, reicht es für schädliches Verhalten, nur eine Rolle zu kontrollieren. Nach der Aufteilung müsste man hingegen, um das Ergebnis zu manipulieren, gleichzeitig sowohl den Produktions- als auch den Witness-/Zeugen-Teil umdrehen – und zwar zwei Gruppen, die völlig unabhängig voneinander sind. Wie man sie auswählt, wie die Identitäten definiert werden und wie Anreize gesetzt werden, ist alles getrennt designt. Dadurch werden die Kosten einer Verschwörung und das Risiko, dabei aufzufliegen, direkt nach oben geschoben.
Die Logik der Trennung von Verantwortlichkeiten und Rechten ist in der traditionellen Governance nichts Neues, aber Dusk „verbackt“ sie im Konsens-Layer als grundlegendes Mechanismusdesign – nicht nur als Behauptung. Das dürfte genau das sein, was SBA lösen möchte.

@Dusk $DUSK #dusk

Was ist das Kern-Design des SBA-Konsenses?

🌏【Thema】Doppelwellen treffen aufeinander: Al + Web3 OI Agent schreibt die Regeln für On-Chain-Finanzen um

📅 【Zeit】16. August 2026 19：30 (UTC+8)

🌕【Einleitung】
Die Brandung wälzt sich dahin, die Zeit iteriert weiter: Man sagt, die Wellen hinter dem Jangtse drücken die vorderen Wellen an, und eine neue Ära löst das Alte ab. Wenn die kluge Welle der künstlichen Intelligenz auf die gewaltige, dezentralisierte Veränderungswelle von Web3 trifft, verschmelzen zwei Ströme der Zeit und formen gerade die gesamte Landschaft der On-Chain-Finanzen neu. Blick zurück auf die Vergangenheit der Branche: Herkömmliche On-Chain-Transaktionen lassen sich kaum vermeiden, dass man müde ist vom ständigen Beobachten mit menschlichen Augen, von störenden subjektiven Emotionen und davon, dass sich riesige Datenmengen nur schwer auswerten lassen – so stecken unzählige Akteure in einer Informationslücke und einer Verzögerung bei Entscheidungen fest.

Heute steigt die KI-Agent-Technologie rasant auf und bringt Web3-Ökosystemen eine völlig neue Lösung: intelligente Entscheidungen, Datenanalyse und automatisierte Ausführung – damit tritt die On-Chain-Finanzierung in eine neue Phase der Intelligenz ein. Chancen und Umbrüche existieren nebeneinander. Nur die Basisinfrastruktur, die sich wirklich umsetzen lässt, kann Zyklen überstehen.

Heute Abend treffen wir uns hier zu einem tiefgehenden Austausch rund um Al + Web3. Im Livestream sind viele Sterne versammelt – wir freuen uns sehr, mehrere Branchen-OGs, erfahrene Experten, führende Streamer auf dem Marktplatz sowie Größen aus Research & Investment mit auf die Bühne zu holen. Wir sind gespannt auf euch!

🎤 Exklusiver Moderator (Host)
🎙Exklusiver Gold-Moderator👉🏻梨浅Grace
@梨浅Grace
🎙Gemeinsamer Moderator👉🏻旭好传媒
@旭好传媒
🎙Gemeinsamer Moderator👉🏻
OI Agent@oiagent_

👥【Exklusiv eingeladene Top-Gäste】（Speakers）
🔹Web3 Peter 张 @Web3Peter张｜Web3 OG
OI Agent erfahrener Produktmanager
🔹星睿 @星睿 ｜Branchen-erfahrener Blockchain-Experte
🔹华佗 @HTWhale ｜Liangshan-Community erfahrener Web3-Experte
🔹ANNA汤圆 @Anna-汤圆 ｜Erfahrene Web3-Binance-Plaza Gold-Label-Streamer
🔹NiKi葡萄 @Niki葡萄 ｜Erfahrener Web3-Investor
🔹YZZ竹竹 @竹竹YZZ ｜Erfahrener Beobachter für Blockchain Research & Investment

📌【Binance-Plaza Livestream-Link】
https://app.binance.com/uni-qr/cspa/44484277780290?l=zh-CN&r=BLA7SFFI&source=host_share&uc=web_square_share_link&us=copylink

📌【Loopspace Livestream-Link】
https://loopspace.xyz/s/yHS7Q9xB9E

Ich schaue mir in diesen Tagen die technischen Dokumente von Dusk an und bin auf eine ziemlich un intuitive Entscheidung gestoßen: Während die meisten Privacy-Chain-Projekte es sich einfach machen und direkt über eine verschlüsselte „Kapsel“ auf dem EVM gehen, macht Dusk genau das nicht. Stattdessen hat Dusk von null eine eigene virtuelle Maschine gebaut.

//
Zuerst: Warum führt der „Kapsel“-Ansatz nicht zum Ziel
Das EVM ist von Anfang an nicht für zk‑Beweise entworfen. Sein Zustandsmodell, der Befehlssatz und die Art, wie Gas abgerechnet wird, sind für „transparente, öffentliche Ausführung“ gedacht. Zwanghaft Zero‑Knowledge‑Proofs in dieses System zu pressen ist im Kern ein Kompromiss auf einer Basis, die nicht auf deine Anforderungen optimiert ist: Die Beweiserstellung dauert langsam, die Schaltkreise sind komplex, und was sich überhaupt verifizieren lässt, wird durch die Architektur selbst stark begrenzt.
Dusk schlägt dafür Piecrust vor – eine virtuelle Maschine, die von Natur aus zk unterstützt. Sie setzt nicht auf EVM‑Kompatibilität, sondern wechselt konsequent die Ausführungsumgebung. Smart Contracts werden nicht zu EVM‑Bytecode kompiliert, sondern zu WASM. Das ist eine moderneres, leichteres, plattformübergreifendes Zwischenformat, das sich von der Basis her leichter „schaltkreisig“ machen und von Beweissystemen verarbeiten lässt.

//
Diese Designidee zeigt sich konkret in mehreren Punkten
Die Ausführung von Verträgen wird in eine abgesicherte, eingeschränkte Umgebung isoliert. Die Schnittstellen, die der Host nutzen kann, werden sehr klein gehalten: Je schmaler die Schnittstelle, desto einfacher wird es nachzuweisen, dass „diese Ausführung ehrlich/korrekt“ war. Die Komplexität des zk‑Beweises hängt direkt mit dieser Aufrufoberfläche zusammen.
WASM selbst besitzt einen Befehlssatz, der sich gut quantifizieren lässt. Das ist besonders hilfreich für die Gas‑Abrechnung in zk‑Diensten: Jede Ausführung hat klar berechenbare Kosten, statt wie beim EVM mit vielen historischen Altlasten und Grenzfällen.
Das Ausführungsergebnis muss auf mehreren Knoten vollständig identisch sein. Das ist die Voraussetzung, damit die nachfolgende Verifikation in der Konsensschicht auf tragfähiger Mathematik aufsetzen kann: Wenn die Ausführung selbst nicht deterministisch ist, kann das Beweissystem noch so stark sein – es lässt sich nicht verifizieren, dass „alle dasselbe Ergebnis berechnet haben“.

//
Im Grunde steckt dahinter dieselbe Entscheidung: Privatsphäre und zk sind keine Funktionen, die man nachträglich „optimierend“ einbauen kann. Man muss die virtuelle Maschine bereits auf der Ebene ihres Instruktionssatzes und des Ausführungsmodells neu entwerfen. Piecrust ist kein Patch für das EVM. Es ist vielmehr das Eingeständnis, dass dieser Weg für zk von Anfang an nicht funktioniert – und ein kompletter Neuanfang.
@Dusk $DUSK #dusk