Binance Square
六出纷飞
2.1k Beiträge

六出纷飞

18年入场,7年老韭菜,年度百大KOL,合约高胜率交易员,公众号:《六出纷飞说》。8折手续费:LCFF888
Creator Awards 2024
Creator Awards 2024
Traders League Badge Beginner
Traders League Badge Beginner
USD1 Halter
USD1 Halter
Regelmäßiger Trader
2.7 Jahre
155 Following
22.1K+ Follower
46.0K+ Like gegeben
2 Abzeichen
Beiträge
PINNED
·
--
PINNED
Vielen Dank an alle Chefs für die Unterstützung, gestern haben wieder Dutzende von Chefs den Rückvergütungsservice aktiviert. Wir sollten sparen, wo wir können, und ausgeben, wo es nötig ist. Der Rückvergütungsanteil für Verträge beträgt 20%, jeden Sonntag werden die Zahlungen an alle rechtzeitig überwiesen. 🎈Einladungs-Code: LCFF666 #手续费返佣
Vielen Dank an alle Chefs für die Unterstützung, gestern haben wieder Dutzende von Chefs den Rückvergütungsservice aktiviert. Wir sollten sparen, wo wir können, und ausgeben, wo es nötig ist. Der Rückvergütungsanteil für Verträge beträgt 20%, jeden Sonntag werden die Zahlungen an alle rechtzeitig überwiesen. 🎈Einladungs-Code: LCFF666
#手续费返佣
·
--
Bullisch
Übersetzung ansehen
听话的小伙伴不会吃亏! 大饼84k进场的,现在吃了两千多刀了 小时线趋势依旧向上,给我拿住了$BTC {future}(BTCUSDT)
听话的小伙伴不会吃亏!
大饼84k进场的,现在吃了两千多刀了
小时线趋势依旧向上,给我拿住了$BTC
六出纷飞
·
--
Bullisch
Der große Kuchen wurde wieder auf 85.000 geschliffen, heute kann man das wirklich so zäh bearbeiten

Ich bin bis 87.300 vorgestoßen, hab aber nicht hinterher gejagt—und als es dann wieder in die Nähe von 84.900 zurückkommt, bin ich plötzlich doch ein bisschen interessiert

Wenn es mir im Bereich 84.200–84.400 noch gibt, nehme ich noch ein bisschen nach; wenn es wirklich weiter nach unten sticht, dann könnte ich bei ~83.300 nochmal nachkaufen. An so einer Position ist das Schlimmste, wenn man sieht, wie es zwei Kerzen steigt, und dann kriegt man Lust, hinterher zu jagen

Oben zuerst bei 85.800 schauen, dann bei dem vorherigen Hoch 87.200.

Diese Marktbewegungen in den letzten Tagen hab ich jetzt wohl verstanden: Wenn man hinterher jagt, wird man geschlagen; wenn man wartet, gibt es aber wieder keine Gelegenheit 😂

$BTC
Seid ihr gerade long oder short mit euren Positionen? #比特币冲击8.7万美元遇阻回落
·
--
Bullisch
Der große Kuchen wurde wieder auf 85.000 geschliffen, heute kann man das wirklich so zäh bearbeiten Ich bin bis 87.300 vorgestoßen, hab aber nicht hinterher gejagt—und als es dann wieder in die Nähe von 84.900 zurückkommt, bin ich plötzlich doch ein bisschen interessiert Wenn es mir im Bereich 84.200–84.400 noch gibt, nehme ich noch ein bisschen nach; wenn es wirklich weiter nach unten sticht, dann könnte ich bei ~83.300 nochmal nachkaufen. An so einer Position ist das Schlimmste, wenn man sieht, wie es zwei Kerzen steigt, und dann kriegt man Lust, hinterher zu jagen Oben zuerst bei 85.800 schauen, dann bei dem vorherigen Hoch 87.200. Diese Marktbewegungen in den letzten Tagen hab ich jetzt wohl verstanden: Wenn man hinterher jagt, wird man geschlagen; wenn man wartet, gibt es aber wieder keine Gelegenheit 😂 $BTC Seid ihr gerade long oder short mit euren Positionen? #比特币冲击8.7万美元遇阻回落 {future}(BTCUSDT)
Der große Kuchen wurde wieder auf 85.000 geschliffen, heute kann man das wirklich so zäh bearbeiten

Ich bin bis 87.300 vorgestoßen, hab aber nicht hinterher gejagt—und als es dann wieder in die Nähe von 84.900 zurückkommt, bin ich plötzlich doch ein bisschen interessiert

Wenn es mir im Bereich 84.200–84.400 noch gibt, nehme ich noch ein bisschen nach; wenn es wirklich weiter nach unten sticht, dann könnte ich bei ~83.300 nochmal nachkaufen. An so einer Position ist das Schlimmste, wenn man sieht, wie es zwei Kerzen steigt, und dann kriegt man Lust, hinterher zu jagen

Oben zuerst bei 85.800 schauen, dann bei dem vorherigen Hoch 87.200.

Diese Marktbewegungen in den letzten Tagen hab ich jetzt wohl verstanden: Wenn man hinterher jagt, wird man geschlagen; wenn man wartet, gibt es aber wieder keine Gelegenheit 😂

$BTC
Seid ihr gerade long oder short mit euren Positionen? #比特币冲击8.7万美元遇阻回落
·
--
Bullisch
Der Bullenmarkt ist schon wieder da – was sollte man kaufen? Für die meisten Menschen reicht es, einfach BTC planmäßig per DCA zu kaufen und sich nicht zu sehr den Kopf zu zerbrechen. Man spielt das Spiel hin und her, am Ende läuft die Kursentwicklung vielleicht trotzdem nicht besser als bei BTC! $BTC {future}(BTCUSDT)
Der Bullenmarkt ist schon wieder da – was sollte man kaufen?
Für die meisten Menschen reicht es, einfach BTC planmäßig per DCA zu kaufen und sich nicht zu sehr den Kopf zu zerbrechen. Man spielt das Spiel hin und her, am Ende läuft die Kursentwicklung vielleicht trotzdem nicht besser als bei BTC! $BTC
·
--
Bullisch
Zwei Tage Zeit, der große Kuchen ist von 7,6 auf 8,1 gestiegen, um 5000 Punkte Liu Ge hat die ganze Zeit offen und klar Long aufgebaut – gibt es noch Geschwister, die im Auto sind? #比特币突破8万美元大关 $BTC {future}(BTCUSDT)
Zwei Tage Zeit, der große Kuchen ist von 7,6 auf 8,1 gestiegen, um 5000 Punkte

Liu Ge hat die ganze Zeit offen und klar Long aufgebaut – gibt es noch Geschwister, die im Auto sind?
#比特币突破8万美元大关 $BTC
六出纷飞
·
--
Bullisch
Gestern haben sie noch gefragt, ob eine Zinserhöhung den Markt in die Tiefe reißen würde. Heute ist die Antwort schon da.

Die US-Notenbank hat die Zinserhöhung umgesetzt – die Negativnachricht ist eingepreist. Also gibt es jetzt erst mal eine kleine Erholung. Als Nächstes schauen wir vor allem auf Bitcoin um 76.700. Kann er sich dort wirklich etablieren? Wenn ja, dann schauen wir uns das nächste Upside-Potenzial an.
Heute Nacht dieses Setup – wie seht ihr das: weiter die Position halten (durchhalten) oder erst einen Teil gewinnsichern?$BTC
·
--
Bullisch
Gestern noch gesagt, ob 76.7000 in der Nähe halten kann—heute ist der große BTC schon bis auf 77.4000 durchgezogen, also als Antwort. BTC und ETH habe ich beide erstmal halbiert, den Rest halte ich weiter. Nachdem ich die Positionen reduziert habe, fühlt sich der verbleibende Gewinn viel angenehmer an, ohne Druck. Was ich verdient habe, stecke ich erst mal in die Tasche, den Rest überlasse ich dem Markt#比特币突破77000美元 $BTC
Gestern noch gesagt, ob 76.7000 in der Nähe halten kann—heute ist der große BTC schon bis auf 77.4000 durchgezogen, also als Antwort.

BTC und ETH habe ich beide erstmal halbiert, den Rest halte ich weiter. Nachdem ich die Positionen reduziert habe, fühlt sich der verbleibende Gewinn viel angenehmer an, ohne Druck.

Was ich verdient habe, stecke ich erst mal in die Tasche, den Rest überlasse ich dem Markt#比特币突破77000美元 $BTC
·
--
Bullisch
Gestern haben sie noch gefragt, ob eine Zinserhöhung den Markt in die Tiefe reißen würde. Heute ist die Antwort schon da. Die US-Notenbank hat die Zinserhöhung umgesetzt – die Negativnachricht ist eingepreist. Also gibt es jetzt erst mal eine kleine Erholung. Als Nächstes schauen wir vor allem auf Bitcoin um 76.700. Kann er sich dort wirklich etablieren? Wenn ja, dann schauen wir uns das nächste Upside-Potenzial an. Heute Nacht dieses Setup – wie seht ihr das: weiter die Position halten (durchhalten) oder erst einen Teil gewinnsichern?$BTC {future}(BTCUSDT)
Gestern haben sie noch gefragt, ob eine Zinserhöhung den Markt in die Tiefe reißen würde. Heute ist die Antwort schon da.

Die US-Notenbank hat die Zinserhöhung umgesetzt – die Negativnachricht ist eingepreist. Also gibt es jetzt erst mal eine kleine Erholung. Als Nächstes schauen wir vor allem auf Bitcoin um 76.700. Kann er sich dort wirklich etablieren? Wenn ja, dann schauen wir uns das nächste Upside-Potenzial an.
Heute Nacht dieses Setup – wie seht ihr das: weiter die Position halten (durchhalten) oder erst einen Teil gewinnsichern?$BTC
Wirklich ganz ohne irgendeinen Callback? Ich wollte schon short gehen $ZEC
Wirklich ganz ohne irgendeinen Callback?
Ich wollte schon short gehen
$ZEC
·
--
Bullisch
Wir hatten zuvor über die Cross-Chain-Brücken gesprochen: Dabei ging es um die Frage, wie „Vermögenswerte von einer Kette auf eine andere verschoben werden“. Diese Woche habe ich dann auf der Website nachgeschaut und entdeckt, dass Dusk noch eine separate Position für „Cross-Chain Message Infrastructure“ („Infrastruktur für Cross-Chain-Nachrichten“) aufführt. Das ist nicht dasselbe wie eine Asset-Bridge—also habe ich mir genauer angesehen, welche Probleme dieser Bereich eigentlich löst. Asset-Bridges kümmern sich um „die Übertragung von Geld und Vermögenswerten“. Die Cross-Chain-Message-Infrastruktur zielt auf eine abstraktere Ebene ab: Wie kommunizieren Anwendungen auf unterschiedlichen Ketten miteinander und lösen gegenseitig Aktionen aus? Zum Beispiel: Wenn ein Smart Contract auf einer Kette eine bestimmte Operation abgeschlossen hat, muss er einen Smart Contract auf einer anderen Kette benachrichtigen, damit dort ein entsprechendes Status-Update durchgeführt wird. Das hat nichts mit einer Vermögensübertragung zu tun—es geht rein um Koordination auf der Ebene von Informationen und Befehlen. Solche Anforderungen sind im heutigen Multi-Chain-Ökosystem immer häufiger anzutreffen und eigentlich grundlegender (und zugleich anspruchsvoller) als reine Asset-Transfers: Bei Asset-Transfers sind Betrag und Richtung immerhin klar; bei der Nachrichtenübermittlung sind die Einsatzszenarien dagegen sehr vielfältig, wodurch die Standardisierung deutlich schwieriger ist. Ich verstehe, warum Dusk in diesen Bereich investieren möchte: Wenn DuskEVM-Anwendungen mit anderen Ketten-Ökosystemen (z. B. dem Ethereum-Hauptnetz oder anderen Layer-2-Netzen) verknüpft werden sollen und nicht nur „einfach eine Asset-Bridge hinüber- und herüber“ genutzt wird, dann braucht es ein zuverlässiges Cross-Chain-Nachrichtenprotokoll. Damit können Smart Contracts auf verschiedenen Ketten miteinander „sprechen“. Das hatten wir zuvor bei DuskTrade schon angedeutet: Wenn das Projekt die institutionelle Investment-Prozesskette wirklich vollständig umsetzen will, wird es in Zukunft sehr wahrscheinlich ebenfalls mit traditionellen Finanzsystemen oder mit Asset-Pools auf anderen Chains gekoppelt werden müssen. In gewisser Weise ebnet diese Cross-Chain-Message-Infrastruktur damit schon heute den Weg für komplexere Multi-Chain-Kooperationsszenarien. Allerdings sind die öffentlich verfügbaren Informationen zu dieser Infrastruktur bislang recht begrenzt. Ob Dusk ein eigenes Protokoll baut oder stattdessen einen bestimmten Drittanbieter-Standard für Cross-Chain-Nachrichten nutzt (etwa so wie LayerZero oder Wormhole als allgemeine Lösungen), habe ich nicht eindeutig herausfinden können. Ich werde wohl warten, bis konkretere technische Dokumente veröffentlicht werden, und dann nochmals genauer hinsehen. Aktuell kann man es nur so einordnen, dass dieser Bereich als Richtung bereits wahrnehmbar ist. @Dusk_Foundation #dusk $DUSK
Wir hatten zuvor über die Cross-Chain-Brücken gesprochen: Dabei ging es um die Frage, wie „Vermögenswerte von einer Kette auf eine andere verschoben werden“. Diese Woche habe ich dann auf der Website nachgeschaut und entdeckt, dass Dusk noch eine separate Position für „Cross-Chain Message Infrastructure“ („Infrastruktur für Cross-Chain-Nachrichten“) aufführt. Das ist nicht dasselbe wie eine Asset-Bridge—also habe ich mir genauer angesehen, welche Probleme dieser Bereich eigentlich löst.

Asset-Bridges kümmern sich um „die Übertragung von Geld und Vermögenswerten“. Die Cross-Chain-Message-Infrastruktur zielt auf eine abstraktere Ebene ab: Wie kommunizieren Anwendungen auf unterschiedlichen Ketten miteinander und lösen gegenseitig Aktionen aus? Zum Beispiel: Wenn ein Smart Contract auf einer Kette eine bestimmte Operation abgeschlossen hat, muss er einen Smart Contract auf einer anderen Kette benachrichtigen, damit dort ein entsprechendes Status-Update durchgeführt wird. Das hat nichts mit einer Vermögensübertragung zu tun—es geht rein um Koordination auf der Ebene von Informationen und Befehlen. Solche Anforderungen sind im heutigen Multi-Chain-Ökosystem immer häufiger anzutreffen und eigentlich grundlegender (und zugleich anspruchsvoller) als reine Asset-Transfers: Bei Asset-Transfers sind Betrag und Richtung immerhin klar; bei der Nachrichtenübermittlung sind die Einsatzszenarien dagegen sehr vielfältig, wodurch die Standardisierung deutlich schwieriger ist.

Ich verstehe, warum Dusk in diesen Bereich investieren möchte: Wenn DuskEVM-Anwendungen mit anderen Ketten-Ökosystemen (z. B. dem Ethereum-Hauptnetz oder anderen Layer-2-Netzen) verknüpft werden sollen und nicht nur „einfach eine Asset-Bridge hinüber- und herüber“ genutzt wird, dann braucht es ein zuverlässiges Cross-Chain-Nachrichtenprotokoll. Damit können Smart Contracts auf verschiedenen Ketten miteinander „sprechen“. Das hatten wir zuvor bei DuskTrade schon angedeutet: Wenn das Projekt die institutionelle Investment-Prozesskette wirklich vollständig umsetzen will, wird es in Zukunft sehr wahrscheinlich ebenfalls mit traditionellen Finanzsystemen oder mit Asset-Pools auf anderen Chains gekoppelt werden müssen. In gewisser Weise ebnet diese Cross-Chain-Message-Infrastruktur damit schon heute den Weg für komplexere Multi-Chain-Kooperationsszenarien.

Allerdings sind die öffentlich verfügbaren Informationen zu dieser Infrastruktur bislang recht begrenzt. Ob Dusk ein eigenes Protokoll baut oder stattdessen einen bestimmten Drittanbieter-Standard für Cross-Chain-Nachrichten nutzt (etwa so wie LayerZero oder Wormhole als allgemeine Lösungen), habe ich nicht eindeutig herausfinden können. Ich werde wohl warten, bis konkretere technische Dokumente veröffentlicht werden, und dann nochmals genauer hinsehen. Aktuell kann man es nur so einordnen, dass dieser Bereich als Richtung bereits wahrnehmbar ist.
@Dusk #dusk $DUSK
·
--
Bärisch
Ich dachte, dass DuskEVM von dem Dusk-Team aus dem Nichts komplett selbst handgestrickt als eine EVM-kompatible Schicht gebaut wurde. Erst als ich tiefer recherchiert habe, habe ich herausgefunden, dass darunter direkt OP Stack genutzt wird – also dieses quelloffene Rollup-Framework, das Optimism selbst entwickelt hat. Diese Erkenntnis hat mein Verständnis von der Positionierung von DuskEVM grundlegend verändert. OP Stack ist ein modularer Framework-Ansatz im Ethereum-Ökosystem, der bereits vielfach verifiziert und von mehreren Layer-2-Ketten breit eingesetzt wird (u. a. Optimism selbst, Base usw.). Er ist speziell dafür ausgelegt, eine EVM-kompatible Ausführungsschicht schnell aufzubauen. Dusk hat sich dagegen entschieden, das Rad neu zu erfinden, sondern ist stattdessen direkt auf diese bereits in großem Maßstab im Einsatz erprobte Grundlage aufgesprungen und hat darauf die eigene Ausführungsumgebung gebaut. Am Ende wird der Zustandsabschluss wieder auf die darunterliegende DuskDS zurückgeführt. Ich finde diese Entscheidung ziemlich pragmatisch: Von Grund auf eine komplett neue EVM-kompatible virtuelle Maschine zu bauen ist mit hohen Risiken und erheblichen Zeitkosten verbunden. Insbesondere sollte die Kernenergie des Dusk-Teams eigentlich stärker in Bereiche fließen, die wirklich differenzierend sind – etwa Kryptografie und Compliance. Indem man auf OP Stack setzt, eine bereits im Ethereum-Ökosystem breit geprüfte und ausgereifte Lösung, kann man große Mengen an Engineering-Aufwand für das wiederholte „Rad-Neuerfinden“ sparen. Gleichzeitig kann man von den Vorteilen profitieren, dass die Rollup-Toolchains im Ethereum-Ökosystem kontinuierlich iterieren – auch OP Stack selbst entwickelt sich ständig weiter. Wenn Dusk den Aktualisierungsrhythmus des Upstream-Ökosystems mitverfolgt, kann es theoretisch dauerhaft von diesen technischen Vorteilen profitieren, ohne eine gesamte VM-Technik-Stack-Lösung komplett eigenständig warten zu müssen. Das bedeutet aber auch, dass die Sicherheits- und Performance-Eigenschaften von DuskEVM in gewissem Maße eng mit der Robustheit dieses Upstream-Frameworks von OP Stack verknüpft sind. Wenn im Upstream ein Sicherheitslückenproblem auftaucht oder es architektonische Anpassungen gibt, muss Dusk in der Regel ebenfalls nachziehen, sich anpassen und reparieren. Es ist also kein vollständig autonom steuerbarer, unabhängiger Technik-Stack. Diese Abhängigkeit ist – vereinfacht gesagt – der „Preis“ dafür, dass man „auf den Schultern von Riesen steht“: Man spart viel Kraft, aber die eigene Kontrolle wird dadurch etwas reduziert. $DUSK Bei der technischen Auswahl – also der Abwägung „Mature Framework übernehmen oder selbst neu erfinden“ – gibt es kein absolutes Richtig oder Falsch. Aber wenn man erst einmal klar versteht, ob das Underlying einer Kette selbst entwickelt wurde oder auf einer Drittanbieter-Architektur basiert, kann man zumindest viel genauer beurteilen, wessen historische Aufzeichnungen als Referenz für die technischen Risiken herangezogen werden sollten. @Dusk_Foundation #dusk {future}(DUSKUSDT)
Ich dachte, dass DuskEVM von dem Dusk-Team aus dem Nichts komplett selbst handgestrickt als eine EVM-kompatible Schicht gebaut wurde. Erst als ich tiefer recherchiert habe, habe ich herausgefunden, dass darunter direkt OP Stack genutzt wird – also dieses quelloffene Rollup-Framework, das Optimism selbst entwickelt hat. Diese Erkenntnis hat mein Verständnis von der Positionierung von DuskEVM grundlegend verändert.

OP Stack ist ein modularer Framework-Ansatz im Ethereum-Ökosystem, der bereits vielfach verifiziert und von mehreren Layer-2-Ketten breit eingesetzt wird (u. a. Optimism selbst, Base usw.). Er ist speziell dafür ausgelegt, eine EVM-kompatible Ausführungsschicht schnell aufzubauen. Dusk hat sich dagegen entschieden, das Rad neu zu erfinden, sondern ist stattdessen direkt auf diese bereits in großem Maßstab im Einsatz erprobte Grundlage aufgesprungen und hat darauf die eigene Ausführungsumgebung gebaut. Am Ende wird der Zustandsabschluss wieder auf die darunterliegende DuskDS zurückgeführt.

Ich finde diese Entscheidung ziemlich pragmatisch: Von Grund auf eine komplett neue EVM-kompatible virtuelle Maschine zu bauen ist mit hohen Risiken und erheblichen Zeitkosten verbunden. Insbesondere sollte die Kernenergie des Dusk-Teams eigentlich stärker in Bereiche fließen, die wirklich differenzierend sind – etwa Kryptografie und Compliance. Indem man auf OP Stack setzt, eine bereits im Ethereum-Ökosystem breit geprüfte und ausgereifte Lösung, kann man große Mengen an Engineering-Aufwand für das wiederholte „Rad-Neuerfinden“ sparen. Gleichzeitig kann man von den Vorteilen profitieren, dass die Rollup-Toolchains im Ethereum-Ökosystem kontinuierlich iterieren – auch OP Stack selbst entwickelt sich ständig weiter. Wenn Dusk den Aktualisierungsrhythmus des Upstream-Ökosystems mitverfolgt, kann es theoretisch dauerhaft von diesen technischen Vorteilen profitieren, ohne eine gesamte VM-Technik-Stack-Lösung komplett eigenständig warten zu müssen.

Das bedeutet aber auch, dass die Sicherheits- und Performance-Eigenschaften von DuskEVM in gewissem Maße eng mit der Robustheit dieses Upstream-Frameworks von OP Stack verknüpft sind. Wenn im Upstream ein Sicherheitslückenproblem auftaucht oder es architektonische Anpassungen gibt, muss Dusk in der Regel ebenfalls nachziehen, sich anpassen und reparieren. Es ist also kein vollständig autonom steuerbarer, unabhängiger Technik-Stack. Diese Abhängigkeit ist – vereinfacht gesagt – der „Preis“ dafür, dass man „auf den Schultern von Riesen steht“: Man spart viel Kraft, aber die eigene Kontrolle wird dadurch etwas reduziert. $DUSK

Bei der technischen Auswahl – also der Abwägung „Mature Framework übernehmen oder selbst neu erfinden“ – gibt es kein absolutes Richtig oder Falsch. Aber wenn man erst einmal klar versteht, ob das Underlying einer Kette selbst entwickelt wurde oder auf einer Drittanbieter-Architektur basiert, kann man zumindest viel genauer beurteilen, wessen historische Aufzeichnungen als Referenz für die technischen Risiken herangezogen werden sollten. @Dusk #dusk
Letzte Woche habe ich fast den BEP20-Release von DUSK, den ich in der Hand hatte, direkt in die Staking-Seite gejagt. Zum Glück habe ich vor dem Absenden nochmal auf die Hinweise geschaut und gemerkt, dass das überhaupt nicht dasselbe ist—ich war kurz komplett schockiert und habe danach die Logik für genau diesen Bereich schnell sauber gemacht. DUSK gibt es aktuell in mehreren Formen: Auf dem Mainnet ist das native DUSK die einzige „wahre“ Version. Außerdem existieren noch historische ERC20-Versionen (auf Ethereum) und BEP20-Versionen (auf der BNB Smart Chain). Diese beiden sind im Kern Tokenisierte Nachweise, die in den frühen Jahren geprägt wurden, als das Mainnet noch nicht live war—vorrangig, um Listings und die Handelbarkeit auf Börsen zu erleichtern. Sie sind nicht dasselbe wie native DUSK und können nicht direkt zum Staking verwendet werden und nicht an Konsensmechanismen teilnehmen. Solche Staking-Protokolle mit nativen Operationen akzeptieren ausschließlich native DUSK. Der offizielle Weg ist eine einseitige Migration: ERC20/BEP20 DUSK wird über den offiziellen Vertrag gesperrt, und das System erzeugt auf dem Mainnet das native DUSK. Die vom Projekt erwartete Zeit dafür liegt bei etwa ein paar Minuten bis knapp über zehn Minuten. Von native DUSK rückwärts zurück nach BEP20 läuft über eine andere, unabhängige Brücke—dabei wird eine feste DUSK-Gebühr erhoben. Die Absicht hinter diesen zwei Pfaden ist sehr klar: Native DUSK wird eindeutig als „einzige maßgebliche Quelle“ definiert, während BEP20 eher als „Shadow Asset“ existiert—für Liquidität und Kompatibilität über Ökosystemgrenzen hinweg—nicht als gleichberechtigte zweite Form. Als ich Recherchen angestellt habe, bin ich zudem auf eine historische Episode gestoßen: Früher sollte die Binance Beacon Chain abgelöst werden. Damals wurde die BEP2-Version von DUSK dazu aufgefordert, innerhalb einer Frist auf BEP20 migriert zu werden. Wenn man nach Ablauf der Deadline nicht migriert hatte, konnte die Version möglicherweise sofort ihre Nutzbarkeit verlieren—das war für mich eine echte Warnung. Bei solchen Token in mehreren Versionen beruht die Stabilität im Hintergrund immer auf der fortlaufenden Pflege der jeweils zugehörigen Ketten und Smart Contracts. Sobald eine Kette oder eine grundlegende Infrastruktur den Rückzug beschließt, müssen die darauf „gewrappeden“ Assets hastig mit umziehen—dauerhaft unveränderlich ist das nicht. Diese Sache war für mich selbst eine Erinnerung: Bevor ich in Richtung Staking oder Operationen rund um das Dusk-Ökosystem gehe, sollte ich zuerst bestätigen, ob das, was ich in der Hand habe, wirklich native DUSK ist. Wenn man das nicht sauber klärt, reicht es schlimmstenfalls von einem simplen Fehlschlag der Aktion bis hin zu massivem Zeitdruck, so wie in den offiziellen historischen Hinweisen zur Asset-Migration. @Dusk_Foundation #dusk $DUSK
Letzte Woche habe ich fast den BEP20-Release von DUSK, den ich in der Hand hatte, direkt in die Staking-Seite gejagt. Zum Glück habe ich vor dem Absenden nochmal auf die Hinweise geschaut und gemerkt, dass das überhaupt nicht dasselbe ist—ich war kurz komplett schockiert und habe danach die Logik für genau diesen Bereich schnell sauber gemacht.

DUSK gibt es aktuell in mehreren Formen: Auf dem Mainnet ist das native DUSK die einzige „wahre“ Version. Außerdem existieren noch historische ERC20-Versionen (auf Ethereum) und BEP20-Versionen (auf der BNB Smart Chain). Diese beiden sind im Kern Tokenisierte Nachweise, die in den frühen Jahren geprägt wurden, als das Mainnet noch nicht live war—vorrangig, um Listings und die Handelbarkeit auf Börsen zu erleichtern. Sie sind nicht dasselbe wie native DUSK und können nicht direkt zum Staking verwendet werden und nicht an Konsensmechanismen teilnehmen. Solche Staking-Protokolle mit nativen Operationen akzeptieren ausschließlich native DUSK.

Der offizielle Weg ist eine einseitige Migration: ERC20/BEP20 DUSK wird über den offiziellen Vertrag gesperrt, und das System erzeugt auf dem Mainnet das native DUSK. Die vom Projekt erwartete Zeit dafür liegt bei etwa ein paar Minuten bis knapp über zehn Minuten. Von native DUSK rückwärts zurück nach BEP20 läuft über eine andere, unabhängige Brücke—dabei wird eine feste DUSK-Gebühr erhoben. Die Absicht hinter diesen zwei Pfaden ist sehr klar: Native DUSK wird eindeutig als „einzige maßgebliche Quelle“ definiert, während BEP20 eher als „Shadow Asset“ existiert—für Liquidität und Kompatibilität über Ökosystemgrenzen hinweg—nicht als gleichberechtigte zweite Form.

Als ich Recherchen angestellt habe, bin ich zudem auf eine historische Episode gestoßen: Früher sollte die Binance Beacon Chain abgelöst werden. Damals wurde die BEP2-Version von DUSK dazu aufgefordert, innerhalb einer Frist auf BEP20 migriert zu werden. Wenn man nach Ablauf der Deadline nicht migriert hatte, konnte die Version möglicherweise sofort ihre Nutzbarkeit verlieren—das war für mich eine echte Warnung. Bei solchen Token in mehreren Versionen beruht die Stabilität im Hintergrund immer auf der fortlaufenden Pflege der jeweils zugehörigen Ketten und Smart Contracts. Sobald eine Kette oder eine grundlegende Infrastruktur den Rückzug beschließt, müssen die darauf „gewrappeden“ Assets hastig mit umziehen—dauerhaft unveränderlich ist das nicht.

Diese Sache war für mich selbst eine Erinnerung: Bevor ich in Richtung Staking oder Operationen rund um das Dusk-Ökosystem gehe, sollte ich zuerst bestätigen, ob das, was ich in der Hand habe, wirklich native DUSK ist. Wenn man das nicht sauber klärt, reicht es schlimmstenfalls von einem simplen Fehlschlag der Aktion bis hin zu massivem Zeitdruck, so wie in den offiziellen historischen Hinweisen zur Asset-Migration.

@Dusk #dusk $DUSK
Ich bin schon immer neugierig gewesen, wie es für Knotenbetreiber bestraft wird, wenn sie böswillig handeln oder offline gehen: Wie genau straft Dusk? Diese Woche habe ich extra die Dokumente zur Bestrafungsmechanik durchgesehen und festgestellt, dass dieses Design ausgefeilter ist, als ich gedacht hatte—keine einfache, grobe Einziehung der Stakings ohne Weiteres. Dusk teilt die Bestrafung in zwei Kategorien ein: Soft und Hard. Die Soft-Bestrafung (soft-slashing) richtet sich an Fälle von „keinem schädlichen Handeln, aber unzureichender Leistung“, zum Beispiel wenn man an der Reihe ist, einen Block zu veröffentlichen, ihn aber nicht broadcastet, oder wenn man über längere Zeit offline ist und nicht mit dem Zeitplan mithalten kann. Das ist keine böswillige Handlung, sondern bremst die Effizienz des Netzwerks—bei Soft-Bestrafung werden keine Coins verbrannt. Stattdessen wird ein Teil des Stakings in einen als Belohnungsauszahlungs-Pool verschoben, wodurch das Gewicht dieser Menge beim anschließenden Los-/Zusatzauswahlprozess sinkt. Außerdem gibt es zunächst eine Verwarnungsmöglichkeit; beim zweiten Verstoß wird man erst dann für ein ganzes Epoch von der Teilnahme suspendiert. Im Kern bedeutet das: „Verringere deine Wahrscheinlichkeit, gezogen zu werden“, nicht „zieh dir direkt Geld ab“. Hard-Bestrafung (hard-slashing) ist hingegen für wirklich böswilliges Verhalten reserviert—z. B. Double-Signing oder das Fälschen ungültiger Blöcke, also Aktionen, die das Netzwerk real und konkret in Gefahr bringen. Nur dafür werden tatsächlich ein Teil des Stakings verbrannt, und man wird außerdem über mehrere Epochs hinweg fortlaufend suspendiert—ohne vorherige Verwarnung. Ich finde, der Gedanke hinter dieser Soft/Hard-Schichtung ist im Wesentlichen, zwei völlig unterschiedliche Problemtypen getrennt zu behandeln: „technische Störungen“ und „subjektiv böswilliges Handeln“. Normale Knotenbetreiber können alle möglichen Wartungs-/Betriebsprobleme haben—Netzwerkschwankungen, Serverneustarts usw., die prinzipiell jedem passieren können. Wenn man solche Ereignisse mit derselben Härte wie gezielte Angriffe gegen das Netzwerk bestrafen würde, würden viele, die sonst gerne Nodes betreiben, zögern; dadurch steigen die psychologischen Einstiegskosten für die Teilnahme zu stark. Umgekehrt kann man nicht „zu nachsichtig“ gegenüber echter Böswilligkeit sein, sonst ist die Netzwerksicherheit nicht zu garantieren. In gewissem Maße ist die Soft/Hard-Aufteilung eine Art Mittelweg zwischen den Zielen „Teilnahme fördern“ und „Böswilligkeit bestrafen“. Ich habe allerdings eine Frage: Wenn bei der Soft-Bestrafung keine Coins verbrannt werden, könnte das manche dazu verleiten, gezielt „am Rand“ zu schlittern—absichtlich eine instabile, aber gerade noch unterhalb der Bestrafungsschwelle liegende Betriebsqualität aufrechtzuerhalten? Schließlich wird ja nicht das Kapital abgezogen, sondern nur die Belohnungswahrscheinlichkeit, also ist der Verlust überschaubar. Dieses marginale Spiel, so wie es im Dokument beschrieben ist, wird dort nicht im Detail behandelt. Ich plane, mir bei Gelegenheit die echten Netzwerkdaten anzusehen, ob es Hinweise auf solche Randverhalten gibt. @Dusk_Foundation #dusk $DUSK
Ich bin schon immer neugierig gewesen, wie es für Knotenbetreiber bestraft wird, wenn sie böswillig handeln oder offline gehen: Wie genau straft Dusk? Diese Woche habe ich extra die Dokumente zur Bestrafungsmechanik durchgesehen und festgestellt, dass dieses Design ausgefeilter ist, als ich gedacht hatte—keine einfache, grobe Einziehung der Stakings ohne Weiteres.

Dusk teilt die Bestrafung in zwei Kategorien ein: Soft und Hard. Die Soft-Bestrafung (soft-slashing) richtet sich an Fälle von „keinem schädlichen Handeln, aber unzureichender Leistung“, zum Beispiel wenn man an der Reihe ist, einen Block zu veröffentlichen, ihn aber nicht broadcastet, oder wenn man über längere Zeit offline ist und nicht mit dem Zeitplan mithalten kann. Das ist keine böswillige Handlung, sondern bremst die Effizienz des Netzwerks—bei Soft-Bestrafung werden keine Coins verbrannt. Stattdessen wird ein Teil des Stakings in einen als Belohnungsauszahlungs-Pool verschoben, wodurch das Gewicht dieser Menge beim anschließenden Los-/Zusatzauswahlprozess sinkt. Außerdem gibt es zunächst eine Verwarnungsmöglichkeit; beim zweiten Verstoß wird man erst dann für ein ganzes Epoch von der Teilnahme suspendiert. Im Kern bedeutet das: „Verringere deine Wahrscheinlichkeit, gezogen zu werden“, nicht „zieh dir direkt Geld ab“.

Hard-Bestrafung (hard-slashing) ist hingegen für wirklich böswilliges Verhalten reserviert—z. B. Double-Signing oder das Fälschen ungültiger Blöcke, also Aktionen, die das Netzwerk real und konkret in Gefahr bringen. Nur dafür werden tatsächlich ein Teil des Stakings verbrannt, und man wird außerdem über mehrere Epochs hinweg fortlaufend suspendiert—ohne vorherige Verwarnung.

Ich finde, der Gedanke hinter dieser Soft/Hard-Schichtung ist im Wesentlichen, zwei völlig unterschiedliche Problemtypen getrennt zu behandeln: „technische Störungen“ und „subjektiv böswilliges Handeln“. Normale Knotenbetreiber können alle möglichen Wartungs-/Betriebsprobleme haben—Netzwerkschwankungen, Serverneustarts usw., die prinzipiell jedem passieren können. Wenn man solche Ereignisse mit derselben Härte wie gezielte Angriffe gegen das Netzwerk bestrafen würde, würden viele, die sonst gerne Nodes betreiben, zögern; dadurch steigen die psychologischen Einstiegskosten für die Teilnahme zu stark. Umgekehrt kann man nicht „zu nachsichtig“ gegenüber echter Böswilligkeit sein, sonst ist die Netzwerksicherheit nicht zu garantieren. In gewissem Maße ist die Soft/Hard-Aufteilung eine Art Mittelweg zwischen den Zielen „Teilnahme fördern“ und „Böswilligkeit bestrafen“.

Ich habe allerdings eine Frage: Wenn bei der Soft-Bestrafung keine Coins verbrannt werden, könnte das manche dazu verleiten, gezielt „am Rand“ zu schlittern—absichtlich eine instabile, aber gerade noch unterhalb der Bestrafungsschwelle liegende Betriebsqualität aufrechtzuerhalten? Schließlich wird ja nicht das Kapital abgezogen, sondern nur die Belohnungswahrscheinlichkeit, also ist der Verlust überschaubar. Dieses marginale Spiel, so wie es im Dokument beschrieben ist, wird dort nicht im Detail behandelt. Ich plane, mir bei Gelegenheit die echten Netzwerkdaten anzusehen, ob es Hinweise auf solche Randverhalten gibt.
@Dusk #dusk $DUSK
Verifiziert
Ich dachte lange, dass On-Chain-Wertpapierhandel im Grunde nur ein simples „Auftrag-abschicken–Ausführung“ ist. Erst als ich das Smart-Bulletin-Board-Design von Dusk gesehen habe, wurde mir klar: Diese Situation ist viel näher an den tatsächlichen Handelsgewohnheiten im Primärmarkt, als ich erwartet hatte. XSC ist ein Vertragsstandard, den Dusk für Wertpapier-Assets definiert hat. Das Kernziel ist, dass der Prozess des Haltens und Handelns solcher Assets vertraulich bleibt, aber dennoch den Audit-Anforderungen genügt. Das Smart Bulletin Board ist ein konkreter Matching-Mechanismus innerhalb des XSC-Ökosystems: Wenn beide Seiten Wertpapiere mit nicht-öffentlichem Handel kaufen oder verkaufen möchten, drücken sie zunächst auf dieser „Aushangtafel“ ihr Interesse aus. Nach erfolgreichem Matching und wenn beide Parteien zustimmen, wird die Transaktion anschließend mithilfe des XSC-Vertrags vertrauenslos abgewickelt. Der gesamte Prozess benötigt keinen Zwischenhändler, der matcht, verifiziert oder Assets in Verwahrung hält. Dieses Design erinnert mich an meinen früheren Kontakt mit dem Verkauf von Private-Equity-Beteiligungen: Solche Transaktionen hängen oft stark von Beziehungen und Mittlern ab. Der Ablauf ist dann langsam, Informationen sind nicht transparent, und der Zwischenhändler nimmt zusätzlich noch eine Gebühr. Im Kern verlagert das Smart Bulletin Board den Prozess des „den richtigen Gegenparten finden“ auf die Blockchain. Käufer und Verkäufer treffen sich direkt auf der Vertragsebene, und wenn man sich einig ist, wird direkt abgewickelt. Ohne diese Makler-Ebene können sich Geschwindigkeit und Kosten theoretisch deutlich verbessern. Allerdings habe ich bemerkt, dass dieser Mechanismus eine natürliche Voraussetzung mitbringt: Die Teilnehmer müssen zunächst eine Whitelist-Prüfung durchlaufen, bevor sie handeln dürfen. Das ist also kein vollständig offener, öffentlicher Markt, sondern ein Zulassungsmechanismus, der speziell für regulierte Wertpapierhandels-Szenarien entworfen wurde. Das steht in völlig anderem Maßstab zu der Logik vieler DeFi-Projekte, bei denen im Prinzip jeder in einen öffentlichen Markt einsteigen kann. Ich halte diese Designentscheidung für den richtigen Weg: Wertpapierhandel ist selbst schon reguliert. Das bedeutet aber auch, dass die Zugänglichkeit dieser Lösung nicht so allgemein und inklusiv ist, wie man vielleicht denkt – genutzt werden kann sie vor allem von lizenzierten Institutionen und qualifizierten Investoren, also nicht von irgendeinem einzelnen Kleinanleger, der direkt teilnehmen kann. Technisch werden zwar die Zwischenhändler entfernt, aber die „Wand“ der Zulassung bleibt dennoch bestehen. Dieses Zusammenspiel finde ich ziemlich realistisch, weil es genau die Spannung zwischen den beiden Zielen „Compliance“ und „Dezentralisierung/Ent-Mittelung“ widerspiegelt: Es ist eben nicht einfach nur eine Auswahl zwischen zwei Optionen oder ein vollständiges gleichzeitiges Erreichen. @Dusk_Foundation #dusk $DUSK
Ich dachte lange, dass On-Chain-Wertpapierhandel im Grunde nur ein simples „Auftrag-abschicken–Ausführung“ ist. Erst als ich das Smart-Bulletin-Board-Design von Dusk gesehen habe, wurde mir klar: Diese Situation ist viel näher an den tatsächlichen Handelsgewohnheiten im Primärmarkt, als ich erwartet hatte.

XSC ist ein Vertragsstandard, den Dusk für Wertpapier-Assets definiert hat. Das Kernziel ist, dass der Prozess des Haltens und Handelns solcher Assets vertraulich bleibt, aber dennoch den Audit-Anforderungen genügt. Das Smart Bulletin Board ist ein konkreter Matching-Mechanismus innerhalb des XSC-Ökosystems: Wenn beide Seiten Wertpapiere mit nicht-öffentlichem Handel kaufen oder verkaufen möchten, drücken sie zunächst auf dieser „Aushangtafel“ ihr Interesse aus. Nach erfolgreichem Matching und wenn beide Parteien zustimmen, wird die Transaktion anschließend mithilfe des XSC-Vertrags vertrauenslos abgewickelt. Der gesamte Prozess benötigt keinen Zwischenhändler, der matcht, verifiziert oder Assets in Verwahrung hält.
Dieses Design erinnert mich an meinen früheren Kontakt mit dem Verkauf von Private-Equity-Beteiligungen: Solche Transaktionen hängen oft stark von Beziehungen und Mittlern ab. Der Ablauf ist dann langsam, Informationen sind nicht transparent, und der Zwischenhändler nimmt zusätzlich noch eine Gebühr.
Im Kern verlagert das Smart Bulletin Board den Prozess des „den richtigen Gegenparten finden“ auf die Blockchain. Käufer und Verkäufer treffen sich direkt auf der Vertragsebene, und wenn man sich einig ist, wird direkt abgewickelt. Ohne diese Makler-Ebene können sich Geschwindigkeit und Kosten theoretisch deutlich verbessern.

Allerdings habe ich bemerkt, dass dieser Mechanismus eine natürliche Voraussetzung mitbringt: Die Teilnehmer müssen zunächst eine Whitelist-Prüfung durchlaufen, bevor sie handeln dürfen. Das ist also kein vollständig offener, öffentlicher Markt, sondern ein Zulassungsmechanismus, der speziell für regulierte Wertpapierhandels-Szenarien entworfen wurde. Das steht in völlig anderem Maßstab zu der Logik vieler DeFi-Projekte, bei denen im Prinzip jeder in einen öffentlichen Markt einsteigen kann. Ich halte diese Designentscheidung für den richtigen Weg: Wertpapierhandel ist selbst schon reguliert. Das bedeutet aber auch, dass die Zugänglichkeit dieser Lösung nicht so allgemein und inklusiv ist, wie man vielleicht denkt – genutzt werden kann sie vor allem von lizenzierten Institutionen und qualifizierten Investoren, also nicht von irgendeinem einzelnen Kleinanleger, der direkt teilnehmen kann.

Technisch werden zwar die Zwischenhändler entfernt, aber die „Wand“ der Zulassung bleibt dennoch bestehen. Dieses Zusammenspiel finde ich ziemlich realistisch, weil es genau die Spannung zwischen den beiden Zielen „Compliance“ und „Dezentralisierung/Ent-Mittelung“ widerspiegelt: Es ist eben nicht einfach nur eine Auswahl zwischen zwei Optionen oder ein vollständiges gleichzeitiges Erreichen.
@Dusk #dusk $DUSK
TermMax über Alpha: Ich habe die Schwelle selbst einmal durchgerechnet Wenn man vom TMX-Gesamtvolumen von 1 Milliarde ausgeht und anhand des aktuellen Marktkapitalisierungs-Bereichs rückwärts rechnet: Wenn man Alpha ungefähr 1% in den Airdrop-Pool gibt, ist das grob in der Größenordnung von Marktkapitalisierung × 1%. Aber TermMax hat vorher schon eine Booster-Aktivität durchlaufen, d. h. es wurde im Voraus ein Teil ausgegeben. Der tatsächliche Anteil, der Alpha verbleibt, wird mit hoher Wahrscheinlichkeit geringer sein; es wird nicht exakt 1% als ganze Zahl sein. Als Referenz für die Airdrops früherer Projekte in ähnlicher Größenordnung: Die Schwelle für 50.000 vollständige Shares lag meist im Bereich von 200–230 Punkten. Wenn man TermMax anhand einer Pro-Kopf-Verteilung hochrechnet, landet es sehr wahrscheinlich in der Nähe dieses Bereichs und ist nicht besonders hoch. Es gibt hier aber noch eine Variable: TermMax ist kein neues Projekt. Es hat bereits etwa 90 Millionen US-Dollar TVL und mehrere hunderttausend registrierte Wallets und gehört damit zu Projekten im Lending-/Borrowing-Segment, die eine gewisse Bekanntheit haben. Bei solchen Projekten ist die Verhandlungsmacht in der Regel stärker als bei komplett neuen Coins. Aufseiten von Binance könnte sich die Zuteilungsquote daher eher nach unten drücken, wodurch sich auch die Schwelle erhöhen kann. Meine eigene Einschätzung: Es ist nicht nötig, sich die Punkte absichtlich zu horten und auf die Schwelle zu warten—normales Vorgehen reicht. Falls die Schwelle doch ungewöhnlich hoch ausfällt, dann verpasst man eben diese Runde. Der Bereich Festzins-Lending bleibt langfristig wertvoll; es fehlt nicht gerade an diesem einen Airdrop. #TermMax @termmax
TermMax über Alpha: Ich habe die Schwelle selbst einmal durchgerechnet

Wenn man vom TMX-Gesamtvolumen von 1 Milliarde ausgeht und anhand des aktuellen Marktkapitalisierungs-Bereichs rückwärts rechnet: Wenn man Alpha ungefähr 1% in den Airdrop-Pool gibt, ist das grob in der Größenordnung von Marktkapitalisierung × 1%.

Aber TermMax hat vorher schon eine Booster-Aktivität durchlaufen, d. h. es wurde im Voraus ein Teil ausgegeben. Der tatsächliche Anteil, der Alpha verbleibt, wird mit hoher Wahrscheinlichkeit geringer sein; es wird nicht exakt 1% als ganze Zahl sein.

Als Referenz für die Airdrops früherer Projekte in ähnlicher Größenordnung: Die Schwelle für 50.000 vollständige Shares lag meist im Bereich von 200–230 Punkten. Wenn man TermMax anhand einer Pro-Kopf-Verteilung hochrechnet, landet es sehr wahrscheinlich in der Nähe dieses Bereichs und ist nicht besonders hoch.

Es gibt hier aber noch eine Variable: TermMax ist kein neues Projekt. Es hat bereits etwa 90 Millionen US-Dollar TVL und mehrere hunderttausend registrierte Wallets und gehört damit zu Projekten im Lending-/Borrowing-Segment, die eine gewisse Bekanntheit haben. Bei solchen Projekten ist die Verhandlungsmacht in der Regel stärker als bei komplett neuen Coins. Aufseiten von Binance könnte sich die Zuteilungsquote daher eher nach unten drücken, wodurch sich auch die Schwelle erhöhen kann.

Meine eigene Einschätzung: Es ist nicht nötig, sich die Punkte absichtlich zu horten und auf die Schwelle zu warten—normales Vorgehen reicht. Falls die Schwelle doch ungewöhnlich hoch ausfällt, dann verpasst man eben diese Runde. Der Bereich Festzins-Lending bleibt langfristig wertvoll; es fehlt nicht gerade an diesem einen Airdrop.

#TermMax @TermMax
Ich habe nebenbei die Hintergründe des Dusk-Core-Teams nachgeschaut und dabei einen recht unintuitiven Punkt gefunden: Der Gründer Emanuele Francioni hat als Fachgebiet Robotik- und Automatisierungsingenieurwesen und ist nicht aus einem klassischen Kryptografie-Studiengang hervorgegangen. In den vorherigen zwanzig Jahren hat er sich vor allem mit verteilten Systemen und byzantinischer Fehlertoleranz beschäftigt, Kryptografie war später ein nachträglich erlerntes Skills-Upgrade im „Skill-Tree“. Aber wirklich die Kryptografie „in der Hand“ hat der Chief Cryptographer Dmitry Khovratovich. Er ist in der Branche kein unbekannter Name: Sowohl die Hash-Algorithmen Equihash als auch Argon2 gehen auf ihn zurück. Ersteres wird von vielen PoW-Ketten genutzt, um ASIC-Mining einzudämmen; Letzteres gilt in der Kryptografie-Community als anerkannter Standard für kryptografisches Hashing. Gleichzeitig arbeitet er als Research Fellow bei der Ethereum Foundation. Eine wissenschaftlich fundierte Kryptograf:in, die sich voll auf das Design der zugrunde liegenden Kryptografie spezialisiert, während der Gründer für Systemarchitektur und die Umsetzung im Engineering zuständig ist – dieses Rollenmodell wirkt auf mich überzeugender als das Narrativ „Der Gründer kann sowohl Kryptografie als auch Engineering“. Die Korrektheit der zugrunde liegenden Mathematik sollte von Fachleuten geprüft werden; das entspricht eher der Logik einer sinnvollen Aufgabenteilung in großen Systemen, statt dass eine Person alles alleine stemmen muss. Doch ich will das auch nicht als Freifahrtschein verstehen – selbst ein sehr guter Kryptograf kann Fehler machen. Das bereits erwähnte Beispiel mit der Verifikationslücke in dusk-plonk zeigt: Eine starke Team-Biografie bedeutet nicht automatisch Null-Risiko im Code. Audits und praktische Validierung sind immer notwendige Ergänzungen – man sollte nie nur die Lebensläufe betrachten. Diese Team-Lebensläufe sind letztlich nur ein Referenzpunkt und kein entscheidender Beweis. Was ich wirklich sehen will, sind die Dinge hinter diesen Namen: die Qualität des Codes, den sie im vergangenen Jahr eingereicht haben, und wie schnell sie auf Sicherheitslücken reagieren. Das ist ehrlicher als jedes Resume. @Dusk_Foundation #dusk $DUSK
Ich habe nebenbei die Hintergründe des Dusk-Core-Teams nachgeschaut und dabei einen recht unintuitiven Punkt gefunden: Der Gründer Emanuele Francioni hat als Fachgebiet Robotik- und Automatisierungsingenieurwesen und ist nicht aus einem klassischen Kryptografie-Studiengang hervorgegangen. In den vorherigen zwanzig Jahren hat er sich vor allem mit verteilten Systemen und byzantinischer Fehlertoleranz beschäftigt, Kryptografie war später ein nachträglich erlerntes Skills-Upgrade im „Skill-Tree“.

Aber wirklich die Kryptografie „in der Hand“ hat der Chief Cryptographer Dmitry Khovratovich. Er ist in der Branche kein unbekannter Name: Sowohl die Hash-Algorithmen Equihash als auch Argon2 gehen auf ihn zurück. Ersteres wird von vielen PoW-Ketten genutzt, um ASIC-Mining einzudämmen; Letzteres gilt in der Kryptografie-Community als anerkannter Standard für kryptografisches Hashing. Gleichzeitig arbeitet er als Research Fellow bei der Ethereum Foundation. Eine wissenschaftlich fundierte Kryptograf:in, die sich voll auf das Design der zugrunde liegenden Kryptografie spezialisiert, während der Gründer für Systemarchitektur und die Umsetzung im Engineering zuständig ist – dieses Rollenmodell wirkt auf mich überzeugender als das Narrativ „Der Gründer kann sowohl Kryptografie als auch Engineering“. Die Korrektheit der zugrunde liegenden Mathematik sollte von Fachleuten geprüft werden; das entspricht eher der Logik einer sinnvollen Aufgabenteilung in großen Systemen, statt dass eine Person alles alleine stemmen muss.

Doch ich will das auch nicht als Freifahrtschein verstehen – selbst ein sehr guter Kryptograf kann Fehler machen. Das bereits erwähnte Beispiel mit der Verifikationslücke in dusk-plonk zeigt: Eine starke Team-Biografie bedeutet nicht automatisch Null-Risiko im Code. Audits und praktische Validierung sind immer notwendige Ergänzungen – man sollte nie nur die Lebensläufe betrachten.

Diese Team-Lebensläufe sind letztlich nur ein Referenzpunkt und kein entscheidender Beweis. Was ich wirklich sehen will, sind die Dinge hinter diesen Namen: die Qualität des Codes, den sie im vergangenen Jahr eingereicht haben, und wie schnell sie auf Sicherheitslücken reagieren. Das ist ehrlicher als jedes Resume.

@Dusk #dusk $DUSK
·
--
Bullisch
Schauen Sie noch zu? Das große Brot ist gleich bei 80.000 In zwei Tagen sind es +10.000 Punkte geworden. Zögern Sie noch, ob Sie leerverkaufen sollen? $BTC {future}(BTCUSDT)
Schauen Sie noch zu? Das große Brot ist gleich bei 80.000
In zwei Tagen sind es +10.000 Punkte geworden. Zögern Sie noch, ob Sie leerverkaufen sollen?
$BTC
Ich wollte einen Teil meiner brachliegenden Ether-Assets rüber auf DuskEVM schieben und es mal ausprobieren. Letzte Nacht bin ich den Cross-Chain-Bridge-Prozess anhand der offiziellen Doku einmal durchgegangen und dokumentiere meine echten Eindrücke: Es war nicht so reibungslos, wie ich mir das vorgestellt hatte. Der Prozess selbst ist nicht kompliziert – auf Ethereum wird eine Lock-Transaktion ausgelöst, man wartet die Bestätigung ab und holt dann auf DuskEVM die entsprechenden Assets ab. Diese Logik unterscheidet sich im Grunde nicht wesentlich von den meisten Cross-Chain-Bridges. Was mich wirklich hat warten lassen, war weniger die Bridge an sich als die Bestätigungszeit: Auf der Ethereum-Seite muss man erst auf genügend Blockbestätigungen warten, bevor die Freigabe erfolgt. Zusätzlich braucht auch DuskEVM mit seinem eigenen Finalitätsmechanismus Zeit, um Vertrauen aufzubauen. Wenn sich die Wartezeiten auf beiden Seiten addieren, ist das eben kein „einmal klicken und sofort ist das Geld da“-Gefühl. Anfangs dachte ich, diese Wartezeit sei ein Mangel beim Erlebnis. Später habe ich aber verstanden, dass das die notwendige „Kosten“ sind: Cross-Chain-Bridges wurden in der Vergangenheit viel zu oft angegriffen oder ausgenutzt. Viele der Bridges, bei denen es schiefging, haben genau aus dem Wunsch nach Tempo ein zu aggressives Bestätigungs-/Finalitäts-Handling gewählt und damit Angreifern mehr Spielraum gegeben. Dusk hat sich entschieden, dass die Finalität auf beiden Seiten erst ausreichend „sitzt“, bevor freigegeben wird. Das ist zwar langsamer – aber zumindest ist diese Designidee eher Sicherheit vor Nutzererlebnis, nicht umgekehrt. Erlebnis-seitig gibt es aber trotzdem Optimierungsmöglichkeiten: Während des Prozesses gab es keine besonders klaren Fortschrittsanzeigen. Nachdem ich die Transaktion angestoßen hatte, war ich eine Weile unsicher, ob ich weiter warten soll oder ob irgendwo ein Schritt feststeckt und ich erneut etwas machen muss. Dieses Ungewissheitsgefühl ist für Erstnutzer nicht besonders freundlich und lässt schnell zweifeln, ob man vielleicht etwas falsch bedient hat. Im Vergleich zu einigen ausgereiften Bridges gibt es hier noch Potenzial bei der Feedback-Mechanik. Außerdem habe ich noch eine Frage, die ich nicht ganz durchdrungen habe: Nachdem die Assets über die Bridge gegangen sind – wie existieren sie dann auf DuskEVM genau? Als native gemappte Assets oder als verpackte Token? Diese Beziehung ist entscheidend dafür, wie die Rücktausch-/Rückzahlungslogik für meine Assets aussieht, falls diese Bridge in Zukunft doch mal ein Problem hat. In der Doku ist diese Stelle nicht sonderlich deutlich erklärt; man muss sich mehrere Ebenen tiefer durchlesen, um die Antwort zusammenzusetzen. Was Cross-Chain-Bridges angeht, war meine Haltung bisher immer: Wenn es sich vermeiden lässt, dann lass es. Wenn es unvermeidbar ist, dann lieber etwas langsamer und dafür mit einem Design, das Sicherheit priorisiert. Nach diesem Praxistest hat Dusk auf jeden Fall die richtige Richtung eingeschlagen – bei den Detail-User-Experiences gibt es aber noch Feinschliff. @Dusk_Foundation #dusk $DUSK
Ich wollte einen Teil meiner brachliegenden Ether-Assets rüber auf DuskEVM schieben und es mal ausprobieren. Letzte Nacht bin ich den Cross-Chain-Bridge-Prozess anhand der offiziellen Doku einmal durchgegangen und dokumentiere meine echten Eindrücke: Es war nicht so reibungslos, wie ich mir das vorgestellt hatte.

Der Prozess selbst ist nicht kompliziert – auf Ethereum wird eine Lock-Transaktion ausgelöst, man wartet die Bestätigung ab und holt dann auf DuskEVM die entsprechenden Assets ab. Diese Logik unterscheidet sich im Grunde nicht wesentlich von den meisten Cross-Chain-Bridges. Was mich wirklich hat warten lassen, war weniger die Bridge an sich als die Bestätigungszeit: Auf der Ethereum-Seite muss man erst auf genügend Blockbestätigungen warten, bevor die Freigabe erfolgt. Zusätzlich braucht auch DuskEVM mit seinem eigenen Finalitätsmechanismus Zeit, um Vertrauen aufzubauen. Wenn sich die Wartezeiten auf beiden Seiten addieren, ist das eben kein „einmal klicken und sofort ist das Geld da“-Gefühl.

Anfangs dachte ich, diese Wartezeit sei ein Mangel beim Erlebnis. Später habe ich aber verstanden, dass das die notwendige „Kosten“ sind: Cross-Chain-Bridges wurden in der Vergangenheit viel zu oft angegriffen oder ausgenutzt. Viele der Bridges, bei denen es schiefging, haben genau aus dem Wunsch nach Tempo ein zu aggressives Bestätigungs-/Finalitäts-Handling gewählt und damit Angreifern mehr Spielraum gegeben. Dusk hat sich entschieden, dass die Finalität auf beiden Seiten erst ausreichend „sitzt“, bevor freigegeben wird. Das ist zwar langsamer – aber zumindest ist diese Designidee eher Sicherheit vor Nutzererlebnis, nicht umgekehrt.

Erlebnis-seitig gibt es aber trotzdem Optimierungsmöglichkeiten: Während des Prozesses gab es keine besonders klaren Fortschrittsanzeigen. Nachdem ich die Transaktion angestoßen hatte, war ich eine Weile unsicher, ob ich weiter warten soll oder ob irgendwo ein Schritt feststeckt und ich erneut etwas machen muss. Dieses Ungewissheitsgefühl ist für Erstnutzer nicht besonders freundlich und lässt schnell zweifeln, ob man vielleicht etwas falsch bedient hat. Im Vergleich zu einigen ausgereiften Bridges gibt es hier noch Potenzial bei der Feedback-Mechanik.

Außerdem habe ich noch eine Frage, die ich nicht ganz durchdrungen habe: Nachdem die Assets über die Bridge gegangen sind – wie existieren sie dann auf DuskEVM genau? Als native gemappte Assets oder als verpackte Token? Diese Beziehung ist entscheidend dafür, wie die Rücktausch-/Rückzahlungslogik für meine Assets aussieht, falls diese Bridge in Zukunft doch mal ein Problem hat. In der Doku ist diese Stelle nicht sonderlich deutlich erklärt; man muss sich mehrere Ebenen tiefer durchlesen, um die Antwort zusammenzusetzen.

Was Cross-Chain-Bridges angeht, war meine Haltung bisher immer: Wenn es sich vermeiden lässt, dann lass es. Wenn es unvermeidbar ist, dann lieber etwas langsamer und dafür mit einem Design, das Sicherheit priorisiert. Nach diesem Praxistest hat Dusk auf jeden Fall die richtige Richtung eingeschlagen – bei den Detail-User-Experiences gibt es aber noch Feinschliff.

@Dusk #dusk $DUSK
Ich dachte lange, dass TermMax beim Ablauf einfach die gängige Vorgehensweise nutzt: „automatisches Closing“ und eine Abrechnung zum Marktpreis der Differenz – bis ich die Dokumente zur Behandlung beim Ablauf nochmal komplett durchgelesen habe und merkte, dass es überhaupt nicht so ist. TermMax verwendet Physical Delivery, also eine Lieferung in Form von realen Vermögenswerten: Zum Ablaufzeitpunkt kann der Inhaber von FT die FT tatsächlich gegen genau 1 Anteil des zugrunde liegenden Debt-Tokens eintauschen. Auf der Borrower-Seite werden die GT-Positionen, sofern sie nicht vorher geschlossen oder verlängert wurden, nach den vereinbarten Regeln direkt abgerechnet – und nicht so, dass das Protokoll dir auf dem Sekundärmarkt einfach einen Preis „abschneidet“, um die Sache zu glätten. Auf den ersten Blick wirkt dieses Design nur wie eine technische Einzelheit, aber in der Praxis hat es einen ziemlichen großen Einfluss. Das Risiko bei Cash-Settlement-ähnlichen Verträgen besteht darin, dass der Abrechnungspreis zum Zeitpunkt des Ablaufs stark von deinen Erwartungen abweichen kann, wenn die Marktliquidität plötzlich austrocknet oder ein Flash-Crash den Preis zum Absturz bringt. Der Vertrag erkennt dann entweder einen Verlust an – oder verlagert den Schaden auf die Gegenpartei. Der Physical-Delivery-Ansatz schneidet diese Unsicherheit komplett weg: Ablauf ist Ablauf. Der Tausch von FT gegen Debt-Token ist fest in der Austauschbeziehung definiert; du musst nicht mehr fragen „Wie viel würde der Markt damals bereit sein zu zahlen?“. Die Parteien im Kreditgeschäft haben sich beim Eröffnen der Position auf den Zinssatz und das Ergebnis zum Laufzeitende festgelegt; dazwischen entsteht wegen der Art der Abwicklung selbst kein zusätzlicher Abweichungseffekt. Doch Physical Delivery hat auch seinen Preis. Es stellt deutlich konkretere Anforderungen an den Borrower: Zum Ablaufdatum muss ausreichend Kapital bereitstehen, um den Debt-Token zurückzuzahlen. Man kann nicht – wie bei manchen Cash-Settlement-Verträgen – in dieser „Lücke“ mit einem „Differenz-Ausgleich“ irgendwie durchrutschen. Wenn vor dem Ablauf keine aktive Verlängerung oder zusätzliche Stellung erfolgt, wird die Positionsbehandlung strikt nach den Vereinbarungen ausgeführt; es gibt kein Protokoll, das dir automatisch einen Kompromisspreis zum sanften Landen liefert. Das bedeutet, dass man bei einem TermMax-Kredit seine eigenen Fälligkeitstermine viel klarer planen muss – es ist kein Produkt, bei dem man sich komplett zurücklehnen kann und alles automatisch beim Ablauf erledigt wird. Ich neige zu der Ansicht, dass dieses Design genau das widerspiegelt, wofür TermMax steht: „fest“ konsequent durchzuziehen – Zinssatz fest, und auch das Ergebnis zum Laufzeitende fest. Der Preis dafür ist, dass Nutzer mehr proaktives Management selbst übernehmen müssen. Das steht im Gegensatz zu der „dummen“ (also komplett automatisierten) Art von Automatisierung, die viele DeFi-Protokolle anstreben. Ob sich das lohnt, hängt davon ab, ob du eher die Sicherheit/Bestimmtheit willst oder eher Bequemlichkeit. @termmax #TermMax
Ich dachte lange, dass TermMax beim Ablauf einfach die gängige Vorgehensweise nutzt: „automatisches Closing“ und eine Abrechnung zum Marktpreis der Differenz – bis ich die Dokumente zur Behandlung beim Ablauf nochmal komplett durchgelesen habe und merkte, dass es überhaupt nicht so ist. TermMax verwendet Physical Delivery, also eine Lieferung in Form von realen Vermögenswerten: Zum Ablaufzeitpunkt kann der Inhaber von FT die FT tatsächlich gegen genau 1 Anteil des zugrunde liegenden Debt-Tokens eintauschen. Auf der Borrower-Seite werden die GT-Positionen, sofern sie nicht vorher geschlossen oder verlängert wurden, nach den vereinbarten Regeln direkt abgerechnet – und nicht so, dass das Protokoll dir auf dem Sekundärmarkt einfach einen Preis „abschneidet“, um die Sache zu glätten.

Auf den ersten Blick wirkt dieses Design nur wie eine technische Einzelheit, aber in der Praxis hat es einen ziemlichen großen Einfluss. Das Risiko bei Cash-Settlement-ähnlichen Verträgen besteht darin, dass der Abrechnungspreis zum Zeitpunkt des Ablaufs stark von deinen Erwartungen abweichen kann, wenn die Marktliquidität plötzlich austrocknet oder ein Flash-Crash den Preis zum Absturz bringt. Der Vertrag erkennt dann entweder einen Verlust an – oder verlagert den Schaden auf die Gegenpartei. Der Physical-Delivery-Ansatz schneidet diese Unsicherheit komplett weg: Ablauf ist Ablauf. Der Tausch von FT gegen Debt-Token ist fest in der Austauschbeziehung definiert; du musst nicht mehr fragen „Wie viel würde der Markt damals bereit sein zu zahlen?“. Die Parteien im Kreditgeschäft haben sich beim Eröffnen der Position auf den Zinssatz und das Ergebnis zum Laufzeitende festgelegt; dazwischen entsteht wegen der Art der Abwicklung selbst kein zusätzlicher Abweichungseffekt.

Doch Physical Delivery hat auch seinen Preis. Es stellt deutlich konkretere Anforderungen an den Borrower: Zum Ablaufdatum muss ausreichend Kapital bereitstehen, um den Debt-Token zurückzuzahlen. Man kann nicht – wie bei manchen Cash-Settlement-Verträgen – in dieser „Lücke“ mit einem „Differenz-Ausgleich“ irgendwie durchrutschen. Wenn vor dem Ablauf keine aktive Verlängerung oder zusätzliche Stellung erfolgt, wird die Positionsbehandlung strikt nach den Vereinbarungen ausgeführt; es gibt kein Protokoll, das dir automatisch einen Kompromisspreis zum sanften Landen liefert. Das bedeutet, dass man bei einem TermMax-Kredit seine eigenen Fälligkeitstermine viel klarer planen muss – es ist kein Produkt, bei dem man sich komplett zurücklehnen kann und alles automatisch beim Ablauf erledigt wird.

Ich neige zu der Ansicht, dass dieses Design genau das widerspiegelt, wofür TermMax steht: „fest“ konsequent durchzuziehen – Zinssatz fest, und auch das Ergebnis zum Laufzeitende fest. Der Preis dafür ist, dass Nutzer mehr proaktives Management selbst übernehmen müssen. Das steht im Gegensatz zu der „dummen“ (also komplett automatisierten) Art von Automatisierung, die viele DeFi-Protokolle anstreben. Ob sich das lohnt, hängt davon ab, ob du eher die Sicherheit/Bestimmtheit willst oder eher Bequemlichkeit.

@TermMax #TermMax
·
--
Bullisch
踏空? 存在的 风浪越大鱼越贵,这种趋势来了就得跟🤫 单边行情是最好滚仓的机会 给不敢上车的兄弟们一个点位👇 币种:✅BTC 方向:多 杠杆:100x 入场挂单:70500-70800(等第一轮回踩,不追现价) 补仓挂单:69400-69800(4小时突破后的回踩区域) 止盈挂单:72800 / 74200 止损挂单:68750 #BTC突破$72000 $BTC {future}(BTCUSDT)
踏空? 存在的
风浪越大鱼越贵,这种趋势来了就得跟🤫
单边行情是最好滚仓的机会
给不敢上车的兄弟们一个点位👇

币种:✅BTC
方向:多
杠杆:100x
入场挂单:70500-70800(等第一轮回踩,不追现价)
补仓挂单:69400-69800(4小时突破后的回踩区域)
止盈挂单:72800 / 74200
止损挂单:68750
#BTC突破$72000 $BTC
Anmelden und weiter Inhalte entdecken
Krypto-Nutzer weltweit auf Binance Square kennenlernen
⚡️ Bleib in Sachen Krypto stets am Puls.
💬 Die weltgrößte Kryptobörse vertraut darauf.
👍 Erhalte verlässliche Einblicke von verifizierten Creators.
E-Mail-Adresse/Telefonnummer
Sitemap
Cookie-Präferenzen
Nutzungsbedingungen der Plattform