Binance Square
西西斯
471 Beiträge

西西斯

落榜美术生,九年圈龄,曾经几乎归零。分享币圈故事和心得,在选择中寻找机会,在失败中顽强成长。 钱包-邀请好友页面输入我的邀请码:XIXISI,享受手续费75折优惠
Trade eröffnen
Hochfrequenz-Trader
8.6 Jahre
40 Following
2.2K+ Follower
304 Like gegeben
Beiträge
Portfolio
PINNED
·
--
Neun Jahre im Krypto-Game, kein Trading, keine Futures, einfach entspannt Profite machen, so sicher wie möglich Geld verdienen. Im Chat werden verschiedene Informationen zum On-Chain Farming geteilt, die Eintrittsbarrieren für Trading-Wettbewerbe besprochen, und es gibt Tutorials für alle Arten von Seekern. Willkommen in Xixisi's Wunderhaus~ Gib auf der Wallet-Seite den Einladungs-Code „XIXISI“ ein, um 25% Rabatt auf die Transaktionsgebühren zu erhalten. Für Freunde, die oft mit der Wallet traden, ist der Gebührenrabatt eine direkte Möglichkeit, den Slippage zu reduzieren.
Neun Jahre im Krypto-Game, kein Trading, keine Futures, einfach entspannt Profite machen, so sicher wie möglich Geld verdienen. Im Chat werden verschiedene Informationen zum On-Chain Farming geteilt, die Eintrittsbarrieren für Trading-Wettbewerbe besprochen, und es gibt Tutorials für alle Arten von Seekern. Willkommen in Xixisi's Wunderhaus~
Gib auf der Wallet-Seite den Einladungs-Code „XIXISI“ ein, um 25% Rabatt auf die Transaktionsgebühren zu erhalten. Für Freunde, die oft mit der Wallet traden, ist der Gebührenrabatt eine direkte Möglichkeit, den Slippage zu reduzieren.
Kürzlich habe ich auf dem Binance-Platz viele Leute rufen sehen, Babylon könne es allen Chains ermöglichen, die Sicherheit von Bitcoin zu teilen—klingt ziemlich beeindruckend. Aber nachdem ich mir das zugrunde liegende Architekturdiagramm von @babylonlabs_io angesehen habe, habe ich festgestellt, dass alle durch diesen eingängigen Spruch völlig in die Irre geführt werden. Wenn man wirklich glaubt, dass die PoW-Hashrate des großen B (Bitcoin) direkt andere Netzwerke schützt, dann liegt man definitiv falsch. Viele gehen selbstverständlich davon aus, dass, sobald man $BTC einlegt, die externe/verknüpfte Chain so etwas wie den Bitcoin-„Security-Moat“ an Hashrate besitzt. In der Realität gilt jedoch: Bitcoin-Miner kümmern sich jeden Tag ausschließlich darum, die eigenen Blöcke für ihr eigenes Ledger zu packen, und sie werden definitiv nicht helfen, Blöcke anderer Chains zu verifizieren—geschweige denn ihnen eine finale Bestätigung geben. Die Rolle, die die eigentliche Arbeit macht, ist der FinalityProvider: Er muss eine Randomness-Commitment übermitteln und dann mit dem EOTS-Signaturmechanismus den Block verbindlich festlegen. Hier spielt BTC im Grunde nicht die Rolle einer Fortführung eines Konsensmechanismus, sondern ganz handfest das wirtschaftliche Sicherheiten-Asset $ETH . Sobald ein Knoten es wagt, mit doppelten Signaturen böse zu handeln, macht EOTS sofort den privaten Schlüssel sichtbar; anschließend folgt das System direkt dem in Taproot hinterlegten Slashing-Pfad und beschlagnahmt bzw. slasht die hinterlegte Sicherheiten. Das bedeutet: Babylon verändert nicht den Konsens des Bitcoin-Mainnets, sondern verwandelt ungenutztes BTC in eine verifizierbare Sicherheit, die jederzeit sanktioniert werden kann. #baby Aus Branchensicht liegt Babylons eigentliche Stärke darin, dass es für jene neu gestarteten öffentlichen Chains die „Startlücke“ löst—nämlich fehlendes Startkapital und eine extrem schlechte Sicherheit. Aber die Frage, die mich jetzt am meisten beschäftigt, ist: Wie groß ist das tatsächliche Interesse am Markt, dass die externen Akteure künftig wirklich Geld ausgeben, um sich diese Sicherheit zu erkaufen, wenn der BTC-Staking-Pool unendlich wächst? Ob Babylons Business-Closed-Loop funktioniert, hängt nicht davon ab, wie viele Dutzende Milliarden an Assets es sperrt, sondern davon, wie viele echte, zahlende Nachfragepunkte am Markt diese Sicherheit tatsächlich stützen. $BABY
Kürzlich habe ich auf dem Binance-Platz viele Leute rufen sehen, Babylon könne es allen Chains ermöglichen, die Sicherheit von Bitcoin zu teilen—klingt ziemlich beeindruckend. Aber nachdem ich mir das zugrunde liegende Architekturdiagramm von @BabylonLabs_io angesehen habe, habe ich festgestellt, dass alle durch diesen eingängigen Spruch völlig in die Irre geführt werden. Wenn man wirklich glaubt, dass die PoW-Hashrate des großen B (Bitcoin) direkt andere Netzwerke schützt, dann liegt man definitiv falsch.
Viele gehen selbstverständlich davon aus, dass, sobald man $BTC einlegt, die externe/verknüpfte Chain so etwas wie den Bitcoin-„Security-Moat“ an Hashrate besitzt. In der Realität gilt jedoch: Bitcoin-Miner kümmern sich jeden Tag ausschließlich darum, die eigenen Blöcke für ihr eigenes Ledger zu packen, und sie werden definitiv nicht helfen, Blöcke anderer Chains zu verifizieren—geschweige denn ihnen eine finale Bestätigung geben. Die Rolle, die die eigentliche Arbeit macht, ist der FinalityProvider: Er muss eine Randomness-Commitment übermitteln und dann mit dem EOTS-Signaturmechanismus den Block verbindlich festlegen.
Hier spielt BTC im Grunde nicht die Rolle einer Fortführung eines Konsensmechanismus, sondern ganz handfest das wirtschaftliche Sicherheiten-Asset $ETH . Sobald ein Knoten es wagt, mit doppelten Signaturen böse zu handeln, macht EOTS sofort den privaten Schlüssel sichtbar; anschließend folgt das System direkt dem in Taproot hinterlegten Slashing-Pfad und beschlagnahmt bzw. slasht die hinterlegte Sicherheiten. Das bedeutet: Babylon verändert nicht den Konsens des Bitcoin-Mainnets, sondern verwandelt ungenutztes BTC in eine verifizierbare Sicherheit, die jederzeit sanktioniert werden kann. #baby
Aus Branchensicht liegt Babylons eigentliche Stärke darin, dass es für jene neu gestarteten öffentlichen Chains die „Startlücke“ löst—nämlich fehlendes Startkapital und eine extrem schlechte Sicherheit. Aber die Frage, die mich jetzt am meisten beschäftigt, ist: Wie groß ist das tatsächliche Interesse am Markt, dass die externen Akteure künftig wirklich Geld ausgeben, um sich diese Sicherheit zu erkaufen, wenn der BTC-Staking-Pool unendlich wächst? Ob Babylons Business-Closed-Loop funktioniert, hängt nicht davon ab, wie viele Dutzende Milliarden an Assets es sperrt, sondern davon, wie viele echte, zahlende Nachfragepunkte am Markt diese Sicherheit tatsächlich stützen. $BABY
Übersetzung ansehen
昨晚在@babylonlabs_io 测试网捣鼓TBV,走完一遍流程我才深刻体会到:想要绝对的去信任,就得拿时间来买单。我锁了0.05个测试网BTC进去,前期操作极度丝滑,连钱包、选个头部DeFi借贷协议、签好Taproot脚本,三分钟完事。但当我尝试模拟清算时,弹出的提示让我陷入沉思:提款居然有几小时到一两天的延迟。这意味着一旦抵押物濒临平仓,系统给的不是瞬间清算,而是硬生生拉出了一个缓冲期。$BABY 翻了Babylon底层说明才知道,这延迟是为了配合BitVM挑战期,给挑战者留出提交欺诈证明的时间。技术上很完美,但套入DeFi场景就很尴尬。如果在浮动利率借贷里遇到极端大暴跌,清算卡上几个小时,$BTC 和稳定币早就脱锚了。难怪圈内老炮都在说TBV天生适合固定利率产品。我查了下,生态里好几个主推的DApp全在搞固定周期借贷,这逻辑就彻底闭环了。 还有一个叫预设提款人的硬核设定。创建金库时,能把币提走的地址必须写死。这带来了偏执狂级别的安全,但也让流动性变得像石头一样僵硬。想换个收益高的协议?你得先还款、关金库、再重头创建。这每一步烧的都是Bitcoin主网的Gas!赶上主网拥堵,一套下来几十美金就没了,小资金玩家完全耗不起。#baby 很多人吐槽TBV比中心化的WBTC慢太多。但我认为Babylon根本没想去卷高频交易,它在做精准的市场切割。对于长期囤币党来说,TBV简直是完美的避风港,$RIVER 资产稳稳躺在自己签名的脚本里,没有任何机构暴雷的风险。它瞄准的是那上万亿美元躺在冷钱包里的闲置资金,这些大佬不在乎多等一天,他们在乎的是那份把私钥死死攥在手里的绝对安全。
昨晚在@BabylonLabs_io 测试网捣鼓TBV,走完一遍流程我才深刻体会到:想要绝对的去信任,就得拿时间来买单。我锁了0.05个测试网BTC进去,前期操作极度丝滑,连钱包、选个头部DeFi借贷协议、签好Taproot脚本,三分钟完事。但当我尝试模拟清算时,弹出的提示让我陷入沉思:提款居然有几小时到一两天的延迟。这意味着一旦抵押物濒临平仓,系统给的不是瞬间清算,而是硬生生拉出了一个缓冲期。$BABY
翻了Babylon底层说明才知道,这延迟是为了配合BitVM挑战期,给挑战者留出提交欺诈证明的时间。技术上很完美,但套入DeFi场景就很尴尬。如果在浮动利率借贷里遇到极端大暴跌,清算卡上几个小时,$BTC 和稳定币早就脱锚了。难怪圈内老炮都在说TBV天生适合固定利率产品。我查了下,生态里好几个主推的DApp全在搞固定周期借贷,这逻辑就彻底闭环了。
还有一个叫预设提款人的硬核设定。创建金库时,能把币提走的地址必须写死。这带来了偏执狂级别的安全,但也让流动性变得像石头一样僵硬。想换个收益高的协议?你得先还款、关金库、再重头创建。这每一步烧的都是Bitcoin主网的Gas!赶上主网拥堵,一套下来几十美金就没了,小资金玩家完全耗不起。#baby
很多人吐槽TBV比中心化的WBTC慢太多。但我认为Babylon根本没想去卷高频交易,它在做精准的市场切割。对于长期囤币党来说,TBV简直是完美的避风港,$RIVER 资产稳稳躺在自己签名的脚本里,没有任何机构暴雷的风险。它瞄准的是那上万亿美元躺在冷钱包里的闲置资金,这些大佬不在乎多等一天,他们在乎的是那份把私钥死死攥在手里的绝对安全。
Übersetzung ansehen
盖摩天大楼的时候大家都喜欢抬头看顶端多炫,却很少有人关心地下打了多深的地基。加密世界里的去中心化也是同一个道理,它绝对不是建好就能自动运转的永动机,而是需要实打实的人工去长期维护。最近在看@babylonlabs_io 的白皮书,第9节讲到多链部署时提到的比特币轻客户端,就像是这座大楼的承重墙。 这个轻客户端干嘛用的?它不需要像全节点那样傻乎乎地去下载几百G的完整账本数据,它只同步区块头信息,利用梅克尔证明来确认你的$BTC 是不是真的被锁在了金库里。只要你想铸造collBTC或者搞稳定币,就必须过它这一关。没有这些轻客户端亲自盯着,所有跨链的资产证明就全成了忽悠人的空头支票。 但是现实问题很骨感,每接入一条新链,就得新建并维护一批轻客户端节点。这些节点可是要烧电费和服务器成本的,光靠爱发电肯定活不长。这时候就轮到白皮书第10节的$BABY 代币经济学出场了。在项目早期,给这些节点发BABY代币本质上就是官方给的运维补贴。等到生态彻底繁荣起来,协议本身产生的$ETH 手续费就会接棒,实现从烧钱赚吆喝到自负盈亏的华丽转身。 所以千万别觉得轻客户端只是个不起眼的代码组件。几十上百条链上的轻客户端编织在一起,才构成了Babylon最硬核的安全护城河。大家总在问#baby 到底有什么价值,其实它锚定的是这群底层盯梢者日夜不休的劳动成本。在这个圈子里,想要最小化信任从来都不是免费的,代币就是我们为安全支付的账单。
盖摩天大楼的时候大家都喜欢抬头看顶端多炫,却很少有人关心地下打了多深的地基。加密世界里的去中心化也是同一个道理,它绝对不是建好就能自动运转的永动机,而是需要实打实的人工去长期维护。最近在看@BabylonLabs_io 的白皮书,第9节讲到多链部署时提到的比特币轻客户端,就像是这座大楼的承重墙。
这个轻客户端干嘛用的?它不需要像全节点那样傻乎乎地去下载几百G的完整账本数据,它只同步区块头信息,利用梅克尔证明来确认你的$BTC 是不是真的被锁在了金库里。只要你想铸造collBTC或者搞稳定币,就必须过它这一关。没有这些轻客户端亲自盯着,所有跨链的资产证明就全成了忽悠人的空头支票。
但是现实问题很骨感,每接入一条新链,就得新建并维护一批轻客户端节点。这些节点可是要烧电费和服务器成本的,光靠爱发电肯定活不长。这时候就轮到白皮书第10节的$BABY 代币经济学出场了。在项目早期,给这些节点发BABY代币本质上就是官方给的运维补贴。等到生态彻底繁荣起来,协议本身产生的$ETH 手续费就会接棒,实现从烧钱赚吆喝到自负盈亏的华丽转身。
所以千万别觉得轻客户端只是个不起眼的代码组件。几十上百条链上的轻客户端编织在一起,才构成了Babylon最硬核的安全护城河。大家总在问#baby 到底有什么价值,其实它锚定的是这群底层盯梢者日夜不休的劳动成本。在这个圈子里,想要最小化信任从来都不是免费的,代币就是我们为安全支付的账单。
Übersetzung ansehen
最近在Binance广场看到很多人发文讨论@babylonlabs_io ,大伙都在喊BTC可以被Slashing了。但只要对大饼底层稍有了解的人都会发问:比特币主网根本没有PoS节点,矿工也压根不认识什么质押规则,Babylon凭什么能真刀真枪地扣掉你钱包里的$BTC ? 一开始我也以为这是靠那个多签委员会强制执行的,但仔细啃完Babylon的密码学白皮书才明白,真正的绝招叫作EOTS。这套机制说白了就像是在门锁里塞了个自毁装置。FinalityProvider在给每个区块投票时都要先押一个随机数,如果在同一个区块高度给两条链都签了名,就等于重用了这个秘密随机数。这一重用,数学上的神奇现象就发生了,节点的私钥会当场裸奔暴露出来。 这一步转换才是最绝的地方!Babylon根本不需要改变比特币主网的共识去让它理解PoS惩罚,而是提前在Taproot脚本里把惩罚交易的路线全画好了。当节点的$ETH 私钥因为双签自爆后,原本缺了密钥而无法发出的惩罚交易,瞬间凑齐了签名条件。这时候广播到比特币主网,矿工只看交易格式合法就打包,$BABY 资产就被真正扣除了。 所以说,Babylon的核心突破是把链下的PoS违规行为,巧妙地翻译成了比特币主网看得懂的签名私钥。不过这种硬核设计也是双刃剑,FP节点的软件稍微出点Bug导致误双签,私钥就会被当场干掉。长期看Babylon,重点不是看它能不能罚恶人,而是看这套密码学转换在实网运行中到底稳不稳定。#baby
最近在Binance广场看到很多人发文讨论@BabylonLabs_io ,大伙都在喊BTC可以被Slashing了。但只要对大饼底层稍有了解的人都会发问:比特币主网根本没有PoS节点,矿工也压根不认识什么质押规则,Babylon凭什么能真刀真枪地扣掉你钱包里的$BTC
一开始我也以为这是靠那个多签委员会强制执行的,但仔细啃完Babylon的密码学白皮书才明白,真正的绝招叫作EOTS。这套机制说白了就像是在门锁里塞了个自毁装置。FinalityProvider在给每个区块投票时都要先押一个随机数,如果在同一个区块高度给两条链都签了名,就等于重用了这个秘密随机数。这一重用,数学上的神奇现象就发生了,节点的私钥会当场裸奔暴露出来。
这一步转换才是最绝的地方!Babylon根本不需要改变比特币主网的共识去让它理解PoS惩罚,而是提前在Taproot脚本里把惩罚交易的路线全画好了。当节点的$ETH 私钥因为双签自爆后,原本缺了密钥而无法发出的惩罚交易,瞬间凑齐了签名条件。这时候广播到比特币主网,矿工只看交易格式合法就打包,$BABY 资产就被真正扣除了。
所以说,Babylon的核心突破是把链下的PoS违规行为,巧妙地翻译成了比特币主网看得懂的签名私钥。不过这种硬核设计也是双刃剑,FP节点的软件稍微出点Bug导致误双签,私钥就会被当场干掉。长期看Babylon,重点不是看它能不能罚恶人,而是看这套密码学转换在实网运行中到底稳不稳定。#baby
Kürzlich reden alle über BTCFi. Viele halten das Abstecken auf #baby für „wie ein Bank-Festgeld“: Sie legen es an, bekommen Erträge, und wenn sie wieder raus wollen, reicht es, einfach auf „Entsperren“ zu klicken. Aber neulich habe ich mich richtig intensiv durch die technischen Unterlagen von Babylon gearbeitet und festgestellt, dass die Realität überhaupt nicht so einfach ist wie „einmal Auszahlen per Klick“. Gerade das Ausstiegs- bzw. Exit-Mechanismus ist die eigentliche Herausforderung für das Verständnis von Privatanlegern. Wenn deine $BTC in den Staking-Status geht, ist sie im Grunde in ein Taproot-Skript „eingesperrt“. Wenn du früher aussteigen willst, musst du eine Unbonding-Transaktion anstoßen. Das ist aber nicht nur deine Entscheidung: Erst wenn das CovenantCommittee die Unterschriften-Schwelle erreicht, werden deine $BABY Coins in einen neuen Zustand namens UnbondingUTXO überführt – und danach musst du noch eine lange Zeit lang die Sperrfrist überstehen. Der kritischste Stolperstein: Denk nicht, dass du, sobald du in die Unbonding-Phase kommst, wirklich komplett „gerettet“ bist! In dieser Phase behält das Skript weiterhin die Auslösekriterien für Slashing bei. Wenn dein beauftragter FinalityProvider-Node Schabernack macht und zweiseitig signiert (Doppelsignierung), dann würde die zugrundeliegende EOTS-Mechanik durch die Wiederverwendung derselben Zufallszahl direkt dein $ETH Private Key „sprengen“. Und selbst wenn du gerade schon dabei bist, dich geordnet aus dem System zu verabschieden, wird dein BTC dennoch gnadenlos vom System bestraft. Wenn du die zugrunde liegende Logik von @babylonlabs_io durchschaut hast, verstehst du: Das große Brot (BTC) hat ursprünglich gar keine so ausgefeilten PoS-Strafmechanismen. Babylon hat diese Regeln einfach mit UTXO, Time Locks und Multisignaturen zusammengebastelt. Für normale Spieler gilt daher: Schau in Zukunft nicht nur darauf, wie geschmeidig der Einstieg ins Staking ist – sondern was wirklich zählt, ist die Frage, welches Wartungs- bzw. Ausstiegsrisiko du übernimmst, wenn du den Exit-Button drückst.
Kürzlich reden alle über BTCFi. Viele halten das Abstecken auf #baby für „wie ein Bank-Festgeld“: Sie legen es an, bekommen Erträge, und wenn sie wieder raus wollen, reicht es, einfach auf „Entsperren“ zu klicken. Aber neulich habe ich mich richtig intensiv durch die technischen Unterlagen von Babylon gearbeitet und festgestellt, dass die Realität überhaupt nicht so einfach ist wie „einmal Auszahlen per Klick“. Gerade das Ausstiegs- bzw. Exit-Mechanismus ist die eigentliche Herausforderung für das Verständnis von Privatanlegern.
Wenn deine $BTC in den Staking-Status geht, ist sie im Grunde in ein Taproot-Skript „eingesperrt“. Wenn du früher aussteigen willst, musst du eine Unbonding-Transaktion anstoßen. Das ist aber nicht nur deine Entscheidung: Erst wenn das CovenantCommittee die Unterschriften-Schwelle erreicht, werden deine $BABY Coins in einen neuen Zustand namens UnbondingUTXO überführt – und danach musst du noch eine lange Zeit lang die Sperrfrist überstehen.
Der kritischste Stolperstein: Denk nicht, dass du, sobald du in die Unbonding-Phase kommst, wirklich komplett „gerettet“ bist! In dieser Phase behält das Skript weiterhin die Auslösekriterien für Slashing bei. Wenn dein beauftragter FinalityProvider-Node Schabernack macht und zweiseitig signiert (Doppelsignierung), dann würde die zugrundeliegende EOTS-Mechanik durch die Wiederverwendung derselben Zufallszahl direkt dein $ETH Private Key „sprengen“. Und selbst wenn du gerade schon dabei bist, dich geordnet aus dem System zu verabschieden, wird dein BTC dennoch gnadenlos vom System bestraft.
Wenn du die zugrunde liegende Logik von @BabylonLabs_io durchschaut hast, verstehst du: Das große Brot (BTC) hat ursprünglich gar keine so ausgefeilten PoS-Strafmechanismen. Babylon hat diese Regeln einfach mit UTXO, Time Locks und Multisignaturen zusammengebastelt. Für normale Spieler gilt daher: Schau in Zukunft nicht nur darauf, wie geschmeidig der Einstieg ins Staking ist – sondern was wirklich zählt, ist die Frage, welches Wartungs- bzw. Ausstiegsrisiko du übernimmst, wenn du den Exit-Button drückst.
Übersetzung ansehen
讨论固定利率产品时,注意力往往集中在借款人获得了什么。融资方能够提前知道期限内的利息支出,确实降低了预算压力。但交易的另一侧是出借人,他们把资金锁进固定合约后,也放弃了利率上升时重新定价的机会。 如果市场利率在合同期内走高,借款人继续享受原有成本,出借人的资金却被锁在较低回报中;如果$ETH 市场利率下降,出借人则可能获得相对优势。固定利率并没有消除风险,而是把利率波动重新分配给交易双方。 Aegis与Babylon的组合要形成稳定市场,必须同时吸引两侧$BTC 资金。只有借款需求,没有愿意承担期限的出借人,报价深度会不足;如果出借人集中在少数期限,借款方也难以获得连续融资。 我希望看到不同期限的资金供给、提前退出规则和二级流动性安排。出借人能否转让头寸,提前离开需要支付多少成本,以及到期资金如何结算,都会影响固定市场的真实可用性。 因此,我看$BABY 不会只关注机构能否锁定借款成本。#baby 还要证明固定收益端具有足够吸引力和流动性。@babylonlabs_io 若能让借贷双方都清楚自己承担的期限风险,市场才不会只剩一侧需求。
讨论固定利率产品时,注意力往往集中在借款人获得了什么。融资方能够提前知道期限内的利息支出,确实降低了预算压力。但交易的另一侧是出借人,他们把资金锁进固定合约后,也放弃了利率上升时重新定价的机会。
如果市场利率在合同期内走高,借款人继续享受原有成本,出借人的资金却被锁在较低回报中;如果$ETH 市场利率下降,出借人则可能获得相对优势。固定利率并没有消除风险,而是把利率波动重新分配给交易双方。
Aegis与Babylon的组合要形成稳定市场,必须同时吸引两侧$BTC 资金。只有借款需求,没有愿意承担期限的出借人,报价深度会不足;如果出借人集中在少数期限,借款方也难以获得连续融资。
我希望看到不同期限的资金供给、提前退出规则和二级流动性安排。出借人能否转让头寸,提前离开需要支付多少成本,以及到期资金如何结算,都会影响固定市场的真实可用性。
因此,我看$BABY 不会只关注机构能否锁定借款成本。#baby 还要证明固定收益端具有足够吸引力和流动性。@BabylonLabs_io 若能让借贷双方都清楚自己承担的期限风险,市场才不会只剩一侧需求。
Übersetzung ansehen
假设一家外部项目首次接入Babylon的安全服务,它可能获得技术支持、测试额度或生态资源。这次合作能够证明产品具备接入条件,却无法单独说明客户愿意长期承担使用$BTC 成本。 真正有信息量的时刻,是第一个服务周期结束以后。对方是否继续采购、有没有扩大覆盖范围、是否愿意从生态补贴转为自身预算,决定了这段关系是联合测试还是稳定业务。 @babylonlabs_io 可以把合作进度分成概念验证、小额生产、正式采购和续约扩容。四个阶段对应完全不同的需求强度。只公布合作名称,会把尚在测试的项目与持续付费客户放在同一口径里。 对于$BABY 经济循环,需求侧续约尤其重要。验证者能够提供多少服务,取决于有多少外部项目愿意购买;用户愿意参与多久,也与服务收入能否持续流入有关。客户预算比社媒热度更接近真实$ETH 购买力。 因此,我看#baby 不会先数活动参与者,而会寻找续约记录。第一次合作说明团队愿意试,第二次付费才说明服务值得留。网络能否形成收入,不由接入仪式决定,而由客户下一张账单决定。
假设一家外部项目首次接入Babylon的安全服务,它可能获得技术支持、测试额度或生态资源。这次合作能够证明产品具备接入条件,却无法单独说明客户愿意长期承担使用$BTC 成本。
真正有信息量的时刻,是第一个服务周期结束以后。对方是否继续采购、有没有扩大覆盖范围、是否愿意从生态补贴转为自身预算,决定了这段关系是联合测试还是稳定业务。
@BabylonLabs_io 可以把合作进度分成概念验证、小额生产、正式采购和续约扩容。四个阶段对应完全不同的需求强度。只公布合作名称,会把尚在测试的项目与持续付费客户放在同一口径里。
对于$BABY 经济循环,需求侧续约尤其重要。验证者能够提供多少服务,取决于有多少外部项目愿意购买;用户愿意参与多久,也与服务收入能否持续流入有关。客户预算比社媒热度更接近真实$ETH 购买力。
因此,我看#baby 不会先数活动参与者,而会寻找续约记录。第一次合作说明团队愿意试,第二次付费才说明服务值得留。网络能否形成收入,不由接入仪式决定,而由客户下一张账单决定。
Übersetzung ansehen
在铁路系统里,两列车不能仅凭司机判断是否可以通过同一段轨道。信号和联锁系统会先检查道岔、区间占用和路线冲突,只有所有条件一致,通行信号才会被放行。速度可以稍慢,状态却不能含糊。 Babylon的时间约束同样可以被看作一套状态联锁。参与、等待、解除和$ETH 异常处置不能同时指向相互冲突的结果。只有当前状态满足预定条件,下一步操作才应该获得执行资格。 这种设计重点不在“锁得更久”,而在于防止流程跳步。用户不能在责任尚未结束时提前离开,系统也不能在解除已经生效后继续按照旧状态计算。顺序被固定以后,$BTC 账本更容易保持一致。 真正的考验发生在多种请求同时到来时。有人进入、有人退出、有人更换提供者,还有部分状态正在接受异常核验。@babylonlabs_io 需要保证这些动作按照一致顺序处理,而不是让前端与底层记录出现两套答案。 因此,我看#baby 会关注状态转换的可观察性。$BABY 的机制如果能让每个阶段都有明确标记,并在请求集中时仍维持一致,时间锁才不只是等待工具,而是一套防止账本冲突的调度系统。
在铁路系统里,两列车不能仅凭司机判断是否可以通过同一段轨道。信号和联锁系统会先检查道岔、区间占用和路线冲突,只有所有条件一致,通行信号才会被放行。速度可以稍慢,状态却不能含糊。
Babylon的时间约束同样可以被看作一套状态联锁。参与、等待、解除和$ETH 异常处置不能同时指向相互冲突的结果。只有当前状态满足预定条件,下一步操作才应该获得执行资格。
这种设计重点不在“锁得更久”,而在于防止流程跳步。用户不能在责任尚未结束时提前离开,系统也不能在解除已经生效后继续按照旧状态计算。顺序被固定以后,$BTC 账本更容易保持一致。
真正的考验发生在多种请求同时到来时。有人进入、有人退出、有人更换提供者,还有部分状态正在接受异常核验。@BabylonLabs_io 需要保证这些动作按照一致顺序处理,而不是让前端与底层记录出现两套答案。
因此,我看#baby 会关注状态转换的可观察性。$BABY 的机制如果能让每个阶段都有明确标记,并在请求集中时仍维持一致,时间锁才不只是等待工具,而是一套防止账本冲突的调度系统。
Übersetzung ansehen
USDB真正要证明的,不是能铸,而是能赎。 判断一种链上稳定资产是否可靠,先别看名字或收益,真正要问3件事:$BTC 由谁保管、赎回条件由谁验证、极端情况下损失由谁承担。@babylonlabs_io 白皮书提出的USDB有意思之处,不是简单给BTC增加用途,而是尝试把信用基础从机构承诺改成可验证的抵押与偿付流程。 按白皮书设想,用户的BTC锁在比特币链上的自托管金库,另一侧协议读取锁定状态后铸造USDB。赎回时,用户先销毁USDB,再提交相应证明以解锁抵押物。这个架构减少了把BTC交给单一托管方的需要,但“少信任”不等于“零风险”:金库脚本、证明系统、跨链状态同步和密钥管理,任意一环失效都可能让赎回受阻。 稳定性最终还要经受清算压力。行情剧烈波动时,预言机延迟、清算流动性不足与链上拥堵可能同时出现,问题就不再只是抵押率够不够,而是执行能否赶在坏账形成前完成。因此我更关注4个参数:清算折扣、价格源降级方案、拥堵时的赎回顺序,以及$ETH 坏账由谁吸收。路线图写得完整,不代表这些问题已经通过实盘验证。 $BABY 也应区分机制与结果。白皮书第10节描述,若协议产生费用,可经拍卖转换为BABY并销毁;只有USDB形成持续使用与真实费用,这条路径才有意义。销毁设计本身不等于价值必然上升。上线后更值得跟踪的是流通规模、抵押覆盖率、真实赎回记录和清算表现。创新可以先被讨论,可靠性仍要由链上数据回答。#baby
USDB真正要证明的,不是能铸,而是能赎。
判断一种链上稳定资产是否可靠,先别看名字或收益,真正要问3件事:$BTC 由谁保管、赎回条件由谁验证、极端情况下损失由谁承担。@BabylonLabs_io 白皮书提出的USDB有意思之处,不是简单给BTC增加用途,而是尝试把信用基础从机构承诺改成可验证的抵押与偿付流程。
按白皮书设想,用户的BTC锁在比特币链上的自托管金库,另一侧协议读取锁定状态后铸造USDB。赎回时,用户先销毁USDB,再提交相应证明以解锁抵押物。这个架构减少了把BTC交给单一托管方的需要,但“少信任”不等于“零风险”:金库脚本、证明系统、跨链状态同步和密钥管理,任意一环失效都可能让赎回受阻。
稳定性最终还要经受清算压力。行情剧烈波动时,预言机延迟、清算流动性不足与链上拥堵可能同时出现,问题就不再只是抵押率够不够,而是执行能否赶在坏账形成前完成。因此我更关注4个参数:清算折扣、价格源降级方案、拥堵时的赎回顺序,以及$ETH 坏账由谁吸收。路线图写得完整,不代表这些问题已经通过实盘验证。
$BABY 也应区分机制与结果。白皮书第10节描述,若协议产生费用,可经拍卖转换为BABY并销毁;只有USDB形成持续使用与真实费用,这条路径才有意义。销毁设计本身不等于价值必然上升。上线后更值得跟踪的是流通规模、抵押覆盖率、真实赎回记录和清算表现。创新可以先被讨论,可靠性仍要由链上数据回答。#baby
Erinnerung: Die Brüder, die als Creator von grvt in die Rangliste gekommen sind, dürfen auf keinen Fall vergessen, auf der Booster-Seite die Verifizierung zu klicken. Dafür hast du nur genau einen Tag Zeit. Es ist so schwer, überhaupt in die Rangliste zu kommen—wenn du die Verifizierung vergisst und die Belohnung dadurch nicht bekommst, wirst du nur noch weinen. #GRVT任务 #ALPHA🔥
Erinnerung: Die Brüder, die als Creator von grvt in die Rangliste gekommen sind, dürfen auf keinen Fall vergessen, auf der Booster-Seite die Verifizierung zu klicken. Dafür hast du nur genau einen Tag Zeit. Es ist so schwer, überhaupt in die Rangliste zu kommen—wenn du die Verifizierung vergisst und die Belohnung dadurch nicht bekommst, wirst du nur noch weinen. #GRVT任务 #ALPHA🔥
Man hört, jemand habe den Jackpot von 99,99 BNB gewonnen. Meine Stimmung ist wie auf dem Avatar. Außerdem: Kann mein ultimativer Gewinn bis morgen vor dem Mittagessen ausgezahlt werden? Wenn nicht, muss ich wieder eine Mahlzeit auslassen #币安9周年
Man hört, jemand habe den Jackpot von 99,99 BNB gewonnen. Meine Stimmung ist wie auf dem Avatar. Außerdem: Kann mein ultimativer Gewinn bis morgen vor dem Mittagessen ausgezahlt werden? Wenn nicht, muss ich wieder eine Mahlzeit auslassen #币安9周年
#BinanceTurns9 neunjähriges Jubiläum – freuen wir uns auf das nächste und jedes weitere neunjährige Jubiläum. Möge Binance immer weiter wachsen und sich verbessern!
#BinanceTurns9 neunjähriges Jubiläum – freuen wir uns auf das nächste und jedes weitere neunjährige Jubiläum. Möge Binance immer weiter wachsen und sich verbessern!
Übersetzung ansehen
昨晚重看@NewtonProtocol 的治理设计,我发现它真正有意思的不是“双层”这个名字,而是谁能改什么。费率、奖励等经济参数交给staked $NEWT 投票,Rollup逻辑和共识升级则要由验证者选择新版本。前者改变$BTC 钱怎么分,后者改变网络按什么规则运行,两类权限分开,本身是合理的风险隔离。 但治理是否有效,不能只看有没有投票页面。参数层至少要公开提案门槛、quorum、通过比例、投票周期和执行延迟,还要披露前10地址的有效投票权。否则规则写着“社区决定”,实际结果仍可能由少数质押主体主导。关键不在谁持币更多,而在集中度能否量化、委托能否撤回、少数意见是否有准备时间。 核心升级更值得看的是“拒绝成本”。验证者理论上可以不采纳新版本,但如果客户端、基础设施和主要流量都由同一方协调,拒绝升级可能等于退出网络。硬分叉只有在代码提前公开、验证者来源足够分散、旧$ETH 链能够继续运行时,才构成真正制衡;否则它更接近技术确认流程,而不是独立治理层。 所以我不会因为Newton仍处早期阶段就否定这套架构,也不会提前把它当成成熟DAO。接下来我更想看到NewtonProtocol发布治理参数表、投票权分布、升级时间锁和验证者采纳记录。对NEWT而言,第一次提案是否通过不是重点;真正的信号是,反对者能否表达、验证者能否拒绝,以及拒绝后是否仍有可行选择。#Newt
昨晚重看@NewtonProtocol 的治理设计,我发现它真正有意思的不是“双层”这个名字,而是谁能改什么。费率、奖励等经济参数交给staked $NEWT 投票,Rollup逻辑和共识升级则要由验证者选择新版本。前者改变$BTC 钱怎么分,后者改变网络按什么规则运行,两类权限分开,本身是合理的风险隔离。
但治理是否有效,不能只看有没有投票页面。参数层至少要公开提案门槛、quorum、通过比例、投票周期和执行延迟,还要披露前10地址的有效投票权。否则规则写着“社区决定”,实际结果仍可能由少数质押主体主导。关键不在谁持币更多,而在集中度能否量化、委托能否撤回、少数意见是否有准备时间。
核心升级更值得看的是“拒绝成本”。验证者理论上可以不采纳新版本,但如果客户端、基础设施和主要流量都由同一方协调,拒绝升级可能等于退出网络。硬分叉只有在代码提前公开、验证者来源足够分散、旧$ETH 链能够继续运行时,才构成真正制衡;否则它更接近技术确认流程,而不是独立治理层。
所以我不会因为Newton仍处早期阶段就否定这套架构,也不会提前把它当成成熟DAO。接下来我更想看到NewtonProtocol发布治理参数表、投票权分布、升级时间锁和验证者采纳记录。对NEWT而言,第一次提案是否通过不是重点;真正的信号是,反对者能否表达、验证者能否拒绝,以及拒绝后是否仍有可行选择。#Newt
Artikel
Übersetzung ansehen
NEWT共享安全的考题:真实罚没必须走完这4步昨天重看@NewtonProtocol 的AVS Architecture,我先把时间线改正了一遍:EigenLayer主网Slashing是在2025年4月17日上线,不是2026年。这个升级确实让再质押从“节点承诺会守规矩”,变成“特定违规可能损失被分配的质押”。但框架出现,不代表Newton自动获得了完整罚没能力。真正的问题不是牙齿装没装上,而是协议能不能准确判断该处罚谁、依据是什么、尺度又该多大。 我把一套有效的AVS罚没拆成4步:先定义可客观验证的错误,再形成任何人都能复查的证据,然后把错误归到具体Operator,最后经过挑战窗口执行处罚。少一环都可能失真。比如Validator批准了一笔不符合Policy的交易,究竟是它故意签错、读取了过期状态,还是不同节点使用了不同版本的规则?若Policy还依赖价格或身份数据,就要继续判断数据源当时是否同步。故障条件没有写成确定性规范,同一结果就可能出现两种解释。 Newton这里最难的是Policy evaluation并非简单双签。输入可能包含$ETH 链上状态、外部数据、Policy版本和TEE证明。TEE远程证明能够说明指定程序在特定环境中运行,却不能单独证明输入数据最新,也不能保证规则本身没有歧义。因此罚没证据至少要绑定Policy哈希、输入状态根、数据时间戳、执行版本和最终输出。还要公开重放方法,让第三方在相同输入下得到相同结果。只有这样,错误证明才有机会从运营判断变成可验证事实。 BLS聚合签名解决了提交效率,却给归责提出了更高要求。聚合结果证明某个委员会达到阈值,不等于天然展示每个签名者的责任。系统还需要保留参与者位图、公钥集合和签名对应的任务编号。若错误attestation已经上链,应该能够追溯哪些Operator实际签过、哪些节点拒签,以及聚合者有没有错误组装参与列表。聚合者自身的责任也要单独定义,否则节点签名正确,最终提交仍可能出错。无法拆解责任的聚合证明,越高效,争议发生时反而越难处理。$NEWT 罚没比例也不是越高越安全。过轻,Operator可能把违规成本当成普通运营费用;过重,RPC状态差异、预言机延迟或客户端Bug都可能让正常节点承担不可控损失,最后只剩资本充足的大型服务商愿意加入。更成熟的设计应该按故障等级区分:离线对应可用性扣减,可证明的错误签名对应更高处罚,存在数据争议的Policy结果则先进入挑战期。处罚上限、紧急暂停、申诉方式和证据保存周期同样重要,$BTC 经济约束不能以制造新的中心化门槛为代价。 共享安全还要看“真正分配给Newton的独立安全预算”,不能只引用EigenLayer整体规模。一个Operator可以同时服务多个AVS,同一套云资源、客户端和运维人员也可能形成相关故障。对Newton更有解释力的数据,是分配给本AVS的有效质押、达到签名阈值所需的最少Operator数量、头部节点占比,以及节点在云厂商和客户端上的重合度。总盘子很大,却由少数主体完成多数签名,安全预算仍可能集中在很窄的故障域里。 所以我的结论不是Newton的AVS没有实质安全,也不是接入EigenLayer后就可以停止追问。Slashing上线只是把惩罚工具交到每个AVS手里,NewtonProtocol仍需公开自己的故障定义、证据格式、处罚曲线、挑战期限和执行记录。我接下来会盯第一份可复现的错误测试、第一场公开罚没演练,以及Operator面板能否展示任务级签名归属。最好再披露误报率、争议处理时间和处罚撤销记录。在检测、归责、裁决和执行真正连成闭环前,我会把共享安全理解为可用能力,而不是已经兑现的结果。#Newt

NEWT共享安全的考题:真实罚没必须走完这4步

昨天重看@NewtonProtocol 的AVS Architecture,我先把时间线改正了一遍:EigenLayer主网Slashing是在2025年4月17日上线,不是2026年。这个升级确实让再质押从“节点承诺会守规矩”,变成“特定违规可能损失被分配的质押”。但框架出现,不代表Newton自动获得了完整罚没能力。真正的问题不是牙齿装没装上,而是协议能不能准确判断该处罚谁、依据是什么、尺度又该多大。
我把一套有效的AVS罚没拆成4步:先定义可客观验证的错误,再形成任何人都能复查的证据,然后把错误归到具体Operator,最后经过挑战窗口执行处罚。少一环都可能失真。比如Validator批准了一笔不符合Policy的交易,究竟是它故意签错、读取了过期状态,还是不同节点使用了不同版本的规则?若Policy还依赖价格或身份数据,就要继续判断数据源当时是否同步。故障条件没有写成确定性规范,同一结果就可能出现两种解释。
Newton这里最难的是Policy evaluation并非简单双签。输入可能包含$ETH 链上状态、外部数据、Policy版本和TEE证明。TEE远程证明能够说明指定程序在特定环境中运行,却不能单独证明输入数据最新,也不能保证规则本身没有歧义。因此罚没证据至少要绑定Policy哈希、输入状态根、数据时间戳、执行版本和最终输出。还要公开重放方法,让第三方在相同输入下得到相同结果。只有这样,错误证明才有机会从运营判断变成可验证事实。
BLS聚合签名解决了提交效率,却给归责提出了更高要求。聚合结果证明某个委员会达到阈值,不等于天然展示每个签名者的责任。系统还需要保留参与者位图、公钥集合和签名对应的任务编号。若错误attestation已经上链,应该能够追溯哪些Operator实际签过、哪些节点拒签,以及聚合者有没有错误组装参与列表。聚合者自身的责任也要单独定义,否则节点签名正确,最终提交仍可能出错。无法拆解责任的聚合证明,越高效,争议发生时反而越难处理。$NEWT
罚没比例也不是越高越安全。过轻,Operator可能把违规成本当成普通运营费用;过重,RPC状态差异、预言机延迟或客户端Bug都可能让正常节点承担不可控损失,最后只剩资本充足的大型服务商愿意加入。更成熟的设计应该按故障等级区分:离线对应可用性扣减,可证明的错误签名对应更高处罚,存在数据争议的Policy结果则先进入挑战期。处罚上限、紧急暂停、申诉方式和证据保存周期同样重要,$BTC 经济约束不能以制造新的中心化门槛为代价。
共享安全还要看“真正分配给Newton的独立安全预算”,不能只引用EigenLayer整体规模。一个Operator可以同时服务多个AVS,同一套云资源、客户端和运维人员也可能形成相关故障。对Newton更有解释力的数据,是分配给本AVS的有效质押、达到签名阈值所需的最少Operator数量、头部节点占比,以及节点在云厂商和客户端上的重合度。总盘子很大,却由少数主体完成多数签名,安全预算仍可能集中在很窄的故障域里。
所以我的结论不是Newton的AVS没有实质安全,也不是接入EigenLayer后就可以停止追问。Slashing上线只是把惩罚工具交到每个AVS手里,NewtonProtocol仍需公开自己的故障定义、证据格式、处罚曲线、挑战期限和执行记录。我接下来会盯第一份可复现的错误测试、第一场公开罚没演练,以及Operator面板能否展示任务级签名归属。最好再披露误报率、争议处理时间和处罚撤销记录。在检测、归责、裁决和执行真正连成闭环前,我会把共享安全理解为可用能力,而不是已经兑现的结果。#Newt
Kürzlich habe ich in @grvt_io mit kleinen bilateralen Limit-Orders getestet, wie der Maker-Return ausfällt. Während des Beobachtungszeitraums lag die Spanne (im ersten Preislevel) bei anhaltend normalem Zustand von $BTC meist bei 0,5–1,5 bp; die im ersten Level sichtbare Tiefe betrug etwa 100.000 USDT. Im nächsten Level erreichte sie häufig 200.000–300.000 USDT. Diese Orderbuch-Tiefe reicht aus, um eine Strategie auf Einzelpersoneniveau unterzubringen. Allerdings entspricht die sichtbare Tiefe auf dem Bildschirm nicht der tatsächlich handelbaren Kapazität—man muss auch die Position der Orders, die Geschwindigkeit beim Zurückziehen und die Erholungsfähigkeit nach aufeinanderfolgenden Treffer-Orders (kontinuierliches „Essen“ der Orders) betrachten. #grvt Während des Tests zeigte das Konto eine Maker-Gebühr von -0,5 bp, also 0,005% Rückerstattung nach dem Ausführen. Ich habe auf beiden Seiten (Kauf und Verkauf) jeweils 1.000 USDT platziert und über 5 Tage kumuliert etwa 420.000 USDT Maker-Orders ausgeführt. Die Rückerstattung plus Ertrag aus der Spanne ergab zusammen etwa 68 USDT; davon trug—basierend auf dieser Gebühr—die Rückerstattung etwa 21 USDT bei, der Rest stammte hauptsächlich aus dem Ergreifen der Spanne. Nach Abzug von Slippage, Bestandsanpassungen und Absicherungs-/Hedge-Kosten blieben tatsächlich 41 USDT übrig, was einem Netto-Ertrag von etwa 9,8 USDT pro 100.000 USDT Handelsvolumen entspricht. Diese Zahl ist aussagekräftiger als eine direkte Umrechnung in eine annualisierte Rendite, denn eine 5-Tage-Stichprobe kann keine Einseitigkeitsmärkte, eine Schrumpfung der Liquidität und Anpassungen der Gebühren abdecken. Mechanisches Hochrechnen verstärkt kurzfristige Ergebnisse und kann die Stabilität der Strategie leicht überschätzen. Dieser Test hat mir bestätigt, dass eine negative Maker-Gebühr zwar einen Puffer bietet, aber nicht der eigentliche Gewinn ist. Entscheidend ist, ob der Ertrag aus der Spanne ausreicht, um Reverse-Selection, Hedge-Kosten und anormale Ausführungen zu überdecken. In Zukunft werde ich weiter 30 Tage lang die Nettoerträge von $ETH , die Dauer von einseitigen Beständen sowie die Preisabweichung nach Ausführungen aufzeichnen, um dann zu entscheiden, ob ich die Größe der Orders weiter erhöhen sollte. Vor der Veröffentlichung der Strategie muss außerdem die aktuellste Gebührenstufe, die zum Konto gehört, erneut überprüft werden.
Kürzlich habe ich in @grvt_io mit kleinen bilateralen Limit-Orders getestet, wie der Maker-Return ausfällt. Während des Beobachtungszeitraums lag die Spanne (im ersten Preislevel) bei anhaltend normalem Zustand von $BTC meist bei 0,5–1,5 bp; die im ersten Level sichtbare Tiefe betrug etwa 100.000 USDT. Im nächsten Level erreichte sie häufig 200.000–300.000 USDT. Diese Orderbuch-Tiefe reicht aus, um eine Strategie auf Einzelpersoneniveau unterzubringen. Allerdings entspricht die sichtbare Tiefe auf dem Bildschirm nicht der tatsächlich handelbaren Kapazität—man muss auch die Position der Orders, die Geschwindigkeit beim Zurückziehen und die Erholungsfähigkeit nach aufeinanderfolgenden Treffer-Orders (kontinuierliches „Essen“ der Orders) betrachten. #grvt
Während des Tests zeigte das Konto eine Maker-Gebühr von -0,5 bp, also 0,005% Rückerstattung nach dem Ausführen. Ich habe auf beiden Seiten (Kauf und Verkauf) jeweils 1.000 USDT platziert und über 5 Tage kumuliert etwa 420.000 USDT Maker-Orders ausgeführt. Die Rückerstattung plus Ertrag aus der Spanne ergab zusammen etwa 68 USDT; davon trug—basierend auf dieser Gebühr—die Rückerstattung etwa 21 USDT bei, der Rest stammte hauptsächlich aus dem Ergreifen der Spanne.
Nach Abzug von Slippage, Bestandsanpassungen und Absicherungs-/Hedge-Kosten blieben tatsächlich 41 USDT übrig, was einem Netto-Ertrag von etwa 9,8 USDT pro 100.000 USDT Handelsvolumen entspricht. Diese Zahl ist aussagekräftiger als eine direkte Umrechnung in eine annualisierte Rendite, denn eine 5-Tage-Stichprobe kann keine Einseitigkeitsmärkte, eine Schrumpfung der Liquidität und Anpassungen der Gebühren abdecken. Mechanisches Hochrechnen verstärkt kurzfristige Ergebnisse und kann die Stabilität der Strategie leicht überschätzen.
Dieser Test hat mir bestätigt, dass eine negative Maker-Gebühr zwar einen Puffer bietet, aber nicht der eigentliche Gewinn ist. Entscheidend ist, ob der Ertrag aus der Spanne ausreicht, um Reverse-Selection, Hedge-Kosten und anormale Ausführungen zu überdecken. In Zukunft werde ich weiter 30 Tage lang die Nettoerträge von $ETH , die Dauer von einseitigen Beständen sowie die Preisabweichung nach Ausführungen aufzeichnen, um dann zu entscheiden, ob ich die Größe der Orders weiter erhöhen sollte. Vor der Veröffentlichung der Strategie muss außerdem die aktuellste Gebührenstufe, die zum Konto gehört, erneut überprüft werden.
Gestern Abend habe ich mir die Sicherheitsarchitektur von @NewtonProtocol erneut angesehen, und mir ist klar geworden, dass EigenLayer eher wie ein gebrauchter Operator-Marktplatz funktioniert. Der Vorteil ist sehr direkt: Newton muss keine Validatoren von Grund auf neu rekrutieren, und die Policy-Validierung kann schneller starten. Gemietete Sicherheit hat aber Grenzen – nicht die Stake-Größe ist die eigentliche Frage, sondern wie viele AVSs diese Knoten gleichzeitig bedienen. $RIVER Wenn mehrere Dienste dieselbe Gruppe an Operatorn, Cloud-Ressourcen und Monitoring-Systeme teilen, sind es auf dem Papier mehrere Netzwerke, aber die Fehlerdomänen können sich überlappen. Wenn ein AVS durch erhöhte Anreize $SYN gewinnt, heißt das nicht zwingend, dass die Knoten Newton verlassen; es kann jedoch das Ressourcen-„Scheduling“ verändern. Aussagekräftiger als „Validierungs-Quote“ sind Daten wie Operator-Überlappung, Anteil der Top-Knoten und die Wiederherstellungszeit, nachdem wichtige Knoten offline gehen. $NEWT Auch bei Slashing muss man die Grenzen klar benennen. Wenn andere AVSs slashed werden, heißt das nicht, dass der Verlust eins zu eins an Newton weitergegeben wird, denn verschiedene Dienste können jeweils eigene Slashing-Bedingungen und Stake-Zuteilungen konfigurieren; aber wenn derselbe Operator wegen Geräte- oder Betriebsproblemen den Service reduziert, kann Newton weiterhin unter Verfügbarkeitsdruck geraten. Das zentrale Risiko ist nicht „ein Slashing, das das ganze Netz mitzieht“, sondern dass mehrere Sicherheitsinstanzen womöglich auf dieselben Ausführenden angewiesen sind. #Newt Daher halte ich EigenLayer für eine sinnvolle Wahl im Cold-Start-Phase von Newton, verstehe „Sicherheit übernehmen“ jedoch nicht als „Risiko ausgelagert“. Als Nächstes würde ich mir vor allem wünschen, dass das NewtonProtocol öffentlich Operator-Konzentration, den Anteil unabhängiger Infrastruktur und Lösungen für Failover veröffentlicht. Wenn künftig unabhängige Knoten und alternative Validierungspfade eingeführt werden können, wird die Authorization Layer nach und nach ihre eigene Zuverlässigkeit aufbauen.
Gestern Abend habe ich mir die Sicherheitsarchitektur von @NewtonProtocol erneut angesehen, und mir ist klar geworden, dass EigenLayer eher wie ein gebrauchter Operator-Marktplatz funktioniert. Der Vorteil ist sehr direkt: Newton muss keine Validatoren von Grund auf neu rekrutieren, und die Policy-Validierung kann schneller starten. Gemietete Sicherheit hat aber Grenzen – nicht die Stake-Größe ist die eigentliche Frage, sondern wie viele AVSs diese Knoten gleichzeitig bedienen. $RIVER
Wenn mehrere Dienste dieselbe Gruppe an Operatorn, Cloud-Ressourcen und Monitoring-Systeme teilen, sind es auf dem Papier mehrere Netzwerke, aber die Fehlerdomänen können sich überlappen. Wenn ein AVS durch erhöhte Anreize $SYN gewinnt, heißt das nicht zwingend, dass die Knoten Newton verlassen; es kann jedoch das Ressourcen-„Scheduling“ verändern. Aussagekräftiger als „Validierungs-Quote“ sind Daten wie Operator-Überlappung, Anteil der Top-Knoten und die Wiederherstellungszeit, nachdem wichtige Knoten offline gehen. $NEWT
Auch bei Slashing muss man die Grenzen klar benennen. Wenn andere AVSs slashed werden, heißt das nicht, dass der Verlust eins zu eins an Newton weitergegeben wird, denn verschiedene Dienste können jeweils eigene Slashing-Bedingungen und Stake-Zuteilungen konfigurieren; aber wenn derselbe Operator wegen Geräte- oder Betriebsproblemen den Service reduziert, kann Newton weiterhin unter Verfügbarkeitsdruck geraten. Das zentrale Risiko ist nicht „ein Slashing, das das ganze Netz mitzieht“, sondern dass mehrere Sicherheitsinstanzen womöglich auf dieselben Ausführenden angewiesen sind. #Newt
Daher halte ich EigenLayer für eine sinnvolle Wahl im Cold-Start-Phase von Newton, verstehe „Sicherheit übernehmen“ jedoch nicht als „Risiko ausgelagert“. Als Nächstes würde ich mir vor allem wünschen, dass das NewtonProtocol öffentlich Operator-Konzentration, den Anteil unabhängiger Infrastruktur und Lösungen für Failover veröffentlicht. Wenn künftig unabhängige Knoten und alternative Validierungspfade eingeführt werden können, wird die Authorization Layer nach und nach ihre eigene Zuverlässigkeit aufbauen.
Artikel
Übersetzung ansehen
Newton真能跨出EVM吗?Chain-Agnostic最难的不是接一条新链昨晚重新看@NewtonProtocol 关于Non-EVM支持的说明,我突然意识到,“chain-agnostic”这个词很容易被理解成一套代码到处部署。可真正的链无关至少分3层:Policy语言能否表达同一条规则、不同链能否提供可信状态、执行权限能否用等价方式落地。Newton目前在EVM环境里的路径相对清楚,非EVM仍在roadmap并不意外;真正值得追问的,是团队准备统一哪一层,又允许哪些部分因链而异。 拿企业财库举例:同样一句“24小时内最多转出2000美元”,放在Base和Solana上并不是换个RPC就结束。$NVDAB 资产精度、账户结构、交易指令、价格来源,甚至“24小时”按区块时间还是自然日计算,都可能不同。Policy Engine可以保留统一语义,但必须先把每条链的原始交易翻译成标准输入。这个翻译层若有偏差,同一条规则就可能在两条链上得到不同答案。 所以非EVM扩展的核心,不一定是让EigenLayer节点直接运行所有链的完整节点,而是建立可审计的Chain Adapter。它负责解析目标链交易、读取必要状态、生成标准化事件,再把结果交给Operator评估。状态来源可以是原生轻客户端、第三方证明网络或受约束的中继服务,每种方案都能工作,却拥有不同的延迟、成本和信任边界。更合理的披露方式,是给Adapter标明验证等级:原生状态证明、外部网络证明,还是带挑战期的乐观确认。文档若只写“支持某条链”,用户仍不知道自己实际信任了谁。$BTC Session Key也是类似问题。EVM里的智能账户和ERC-4337提供了一套成熟工具,但“临时授权”并不等于必须复制同一种账户模型。Solana等链完全可以通过原生程序、委托权限或专用账户实现相似能力。Newton更现实的路线,应该是统一能力描述:允许哪些动作、资产上限多少、何时过期、如何撤销;底层签名和账户结构则由各链适配器实现。真正需要证明的是,不同实现能否提供等价的最小权限,而不是接口名称是否相同。$NEWT 证明成本同样不能只看一笔Gas。不同链支持的密码学原语、计算预算和最终性模型不同,聚合证明未必适合原样搬运。团队可以选择批量验证、递归证明,或者把部分计算放到链下再提交可验证结果,但每次优化都会重新划定信任边界。我更关心4个指标:单条Policy的总延迟、最终确认时间、失败后的回滚方式,以及用户实际支付的完整费用。多链成本不必完全相等,但保障等级和降级路径必须说清楚,否则所谓统一体验只是把差异藏到了后台。 在我看来,roadmap下一步最有价值的不是先公布支持多少条链,而是交出一份适配规范:标准Policy输入长什么样,状态证明由谁生成,Adapter升级由谁控制,跨链消息过期后怎样处理,目标链暂停时权限是否自动冻结。还要有版本兼容规则,避免Adapter更新后,同一份Policy出现不同解释。再配一组公开测试向量,让开发者把同一条限额规则同时跑在EVM和非EVM环境里,对照结果是否一致。一个能复现的devnet示例,比一长串网络Logo更有说服力。 因此我不把“Non-EVM仍在roadmap”直接理解成缺点。先在结构相近的EVM生态验证产品,再扩展到差异更大的运行环境,是合理的工程顺序。但对NewtonProtocol而言,chain-agnostic最终不能只代表“未来会接更多链”,而应代表同一条Policy换到另一条链后,保护强度不会悄悄缩水,新增信任也会被明确披露。接下来我会盯技术草案、Adapter代码、跨链失败语义和首个公开测试环境;在这些东西出现前,我会把非EVM支持视为待验证能力,而不是已经完成的网络效应。#Newt

Newton真能跨出EVM吗?Chain-Agnostic最难的不是接一条新链

昨晚重新看@NewtonProtocol 关于Non-EVM支持的说明,我突然意识到,“chain-agnostic”这个词很容易被理解成一套代码到处部署。可真正的链无关至少分3层:Policy语言能否表达同一条规则、不同链能否提供可信状态、执行权限能否用等价方式落地。Newton目前在EVM环境里的路径相对清楚,非EVM仍在roadmap并不意外;真正值得追问的,是团队准备统一哪一层,又允许哪些部分因链而异。
拿企业财库举例:同样一句“24小时内最多转出2000美元”,放在Base和Solana上并不是换个RPC就结束。$NVDAB 资产精度、账户结构、交易指令、价格来源,甚至“24小时”按区块时间还是自然日计算,都可能不同。Policy Engine可以保留统一语义,但必须先把每条链的原始交易翻译成标准输入。这个翻译层若有偏差,同一条规则就可能在两条链上得到不同答案。
所以非EVM扩展的核心,不一定是让EigenLayer节点直接运行所有链的完整节点,而是建立可审计的Chain Adapter。它负责解析目标链交易、读取必要状态、生成标准化事件,再把结果交给Operator评估。状态来源可以是原生轻客户端、第三方证明网络或受约束的中继服务,每种方案都能工作,却拥有不同的延迟、成本和信任边界。更合理的披露方式,是给Adapter标明验证等级:原生状态证明、外部网络证明,还是带挑战期的乐观确认。文档若只写“支持某条链”,用户仍不知道自己实际信任了谁。$BTC
Session Key也是类似问题。EVM里的智能账户和ERC-4337提供了一套成熟工具,但“临时授权”并不等于必须复制同一种账户模型。Solana等链完全可以通过原生程序、委托权限或专用账户实现相似能力。Newton更现实的路线,应该是统一能力描述:允许哪些动作、资产上限多少、何时过期、如何撤销;底层签名和账户结构则由各链适配器实现。真正需要证明的是,不同实现能否提供等价的最小权限,而不是接口名称是否相同。$NEWT
证明成本同样不能只看一笔Gas。不同链支持的密码学原语、计算预算和最终性模型不同,聚合证明未必适合原样搬运。团队可以选择批量验证、递归证明,或者把部分计算放到链下再提交可验证结果,但每次优化都会重新划定信任边界。我更关心4个指标:单条Policy的总延迟、最终确认时间、失败后的回滚方式,以及用户实际支付的完整费用。多链成本不必完全相等,但保障等级和降级路径必须说清楚,否则所谓统一体验只是把差异藏到了后台。
在我看来,roadmap下一步最有价值的不是先公布支持多少条链,而是交出一份适配规范:标准Policy输入长什么样,状态证明由谁生成,Adapter升级由谁控制,跨链消息过期后怎样处理,目标链暂停时权限是否自动冻结。还要有版本兼容规则,避免Adapter更新后,同一份Policy出现不同解释。再配一组公开测试向量,让开发者把同一条限额规则同时跑在EVM和非EVM环境里,对照结果是否一致。一个能复现的devnet示例,比一长串网络Logo更有说服力。
因此我不把“Non-EVM仍在roadmap”直接理解成缺点。先在结构相近的EVM生态验证产品,再扩展到差异更大的运行环境,是合理的工程顺序。但对NewtonProtocol而言,chain-agnostic最终不能只代表“未来会接更多链”,而应代表同一条Policy换到另一条链后,保护强度不会悄悄缩水,新增信任也会被明确披露。接下来我会盯技术草案、Adapter代码、跨链失败语义和首个公开测试环境;在这些东西出现前,我会把非EVM支持视为待验证能力,而不是已经完成的网络效应。#Newt
Ich habe auf dem Testnetz @grvt_io in ein und dasselbe Cross-Margin-Konto gleichzeitig eine BTC-5x-Long-Position und eine ETH-8x-Long-Position eingezahlt. Eigentlich wollte ich prüfen, ob die einheitliche Margin die Kapitalausnutzung verbessern kann. Am Ende ist jedoch das Wichtigste, das es zu dokumentieren gilt, nicht der Auslöser-Preis, sondern wie kurz die Zeit ist, die dem Konto nach Abschluss der ersten Risiko-Behandlung bleibt, bis der Markt sich wieder erholen kann. Zwei Positionen in die gleiche Richtung teilen sich USDC; sobald die Korrelation plötzlich ansteigt, kann sich eine Streuung der gehaltenen Positionen leicht in dieselbe Risikoweite verwandeln. #grvt Bei einer Simulation eines schnellen Preisrückgangs um 8% für $BTC senkte meine spezielle getestete Version zunächst die Positionsmenge, die zur Wiederherstellung der Maintenance-Margin nötig war; die verbleibenden Orders gingen dann in das Orderbuch, um auf eine Ausführung zu warten. Hier muss ich betonen: In jüngsten öffentlich zugänglichen Inhalten wird für GRVT ein „vollständiges Clearing“ der geltenden Regeln beschrieben. Daher können meine Ergebnisse nur für die damalige Testkonfiguration stehen und nicht direkt als aktueller, formaler Mechanismus verstanden werden. Die wirklich wiederverwendbare Erkenntnis ist: Das Risiko endet nach dem Clearing nicht sofort. Die erste Behandlung war in weniger als 2 Sekunden abgeschlossen; währenddessen ging der externe Preis weiter nach unten. Die Kontorechte fielen erneut unter die Schwelle. Zu diesem Zeitpunkt war die freigesetzte Margin noch nicht zu einem ausreichenden Puffer geworden, und die Kauforder-Tiefe war gerade erst durch die Orders aus der vorherigen Runde aufgebraucht worden. Dadurch wurde eine zweite Auslösung noch wahrscheinlicher. Das Problem ist nicht nur die Höhe des Hebels, sondern dass sich die Aktualisierungsgeschwindigkeit des Preises, die Häufigkeit der Risikoüberprüfung und die Geschwindigkeit des Nachfüllens im Orderbuch innerhalb desselben Zeitfensters gegeneinander „verzogen“ haben. Das hat mir geholfen, Cross-Margin $ETH neu zu verstehen: Sie bündelt im ruhigen Markt die Salden, drückt aber auch mehrere gleichgerichtete Positionen in eine gemeinsame Clearing-Grenze. Bei der Bewertung von GRVT sollte man nicht nur darauf schauen, „ob ein Clearing ausgelöst wurde“, sondern auch die Zeitabstände zwischen den beiden Auslösungen, den Anteil der ersten ausgeführten Trades, die Wiederherstellungszeit bis zur 2%-Tiefe und die verbleibenden Rechte nach der zweiten Behandlung dokumentieren. Erst wenn diese Daten gleichzeitig veröffentlicht sind, können Trader beurteilen, ob die einheitliche Margin tatsächlich die Effizienz verbessert oder lediglich die Zeit für Korrekturen verkürzt.
Ich habe auf dem Testnetz @grvt_io in ein und dasselbe Cross-Margin-Konto gleichzeitig eine BTC-5x-Long-Position und eine ETH-8x-Long-Position eingezahlt. Eigentlich wollte ich prüfen, ob die einheitliche Margin die Kapitalausnutzung verbessern kann. Am Ende ist jedoch das Wichtigste, das es zu dokumentieren gilt, nicht der Auslöser-Preis, sondern wie kurz die Zeit ist, die dem Konto nach Abschluss der ersten Risiko-Behandlung bleibt, bis der Markt sich wieder erholen kann. Zwei Positionen in die gleiche Richtung teilen sich USDC; sobald die Korrelation plötzlich ansteigt, kann sich eine Streuung der gehaltenen Positionen leicht in dieselbe Risikoweite verwandeln. #grvt
Bei einer Simulation eines schnellen Preisrückgangs um 8% für $BTC senkte meine spezielle getestete Version zunächst die Positionsmenge, die zur Wiederherstellung der Maintenance-Margin nötig war; die verbleibenden Orders gingen dann in das Orderbuch, um auf eine Ausführung zu warten. Hier muss ich betonen: In jüngsten öffentlich zugänglichen Inhalten wird für GRVT ein „vollständiges Clearing“ der geltenden Regeln beschrieben. Daher können meine Ergebnisse nur für die damalige Testkonfiguration stehen und nicht direkt als aktueller, formaler Mechanismus verstanden werden. Die wirklich wiederverwendbare Erkenntnis ist: Das Risiko endet nach dem Clearing nicht sofort.
Die erste Behandlung war in weniger als 2 Sekunden abgeschlossen; währenddessen ging der externe Preis weiter nach unten. Die Kontorechte fielen erneut unter die Schwelle. Zu diesem Zeitpunkt war die freigesetzte Margin noch nicht zu einem ausreichenden Puffer geworden, und die Kauforder-Tiefe war gerade erst durch die Orders aus der vorherigen Runde aufgebraucht worden. Dadurch wurde eine zweite Auslösung noch wahrscheinlicher. Das Problem ist nicht nur die Höhe des Hebels, sondern dass sich die Aktualisierungsgeschwindigkeit des Preises, die Häufigkeit der Risikoüberprüfung und die Geschwindigkeit des Nachfüllens im Orderbuch innerhalb desselben Zeitfensters gegeneinander „verzogen“ haben.
Das hat mir geholfen, Cross-Margin $ETH neu zu verstehen: Sie bündelt im ruhigen Markt die Salden, drückt aber auch mehrere gleichgerichtete Positionen in eine gemeinsame Clearing-Grenze. Bei der Bewertung von GRVT sollte man nicht nur darauf schauen, „ob ein Clearing ausgelöst wurde“, sondern auch die Zeitabstände zwischen den beiden Auslösungen, den Anteil der ersten ausgeführten Trades, die Wiederherstellungszeit bis zur 2%-Tiefe und die verbleibenden Rechte nach der zweiten Behandlung dokumentieren. Erst wenn diese Daten gleichzeitig veröffentlicht sind, können Trader beurteilen, ob die einheitliche Margin tatsächlich die Effizienz verbessert oder lediglich die Zeit für Korrekturen verkürzt.
$QQQB 组池子的老哥被套了,今天钱包刷分磨损并不小,最关键的是,一群人研究怎么刷分,结果空投没了😔 #ALPHA
$QQQB 组池子的老哥被套了,今天钱包刷分磨损并不小,最关键的是,一群人研究怎么刷分,结果空投没了😔
#ALPHA
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