die letzte angle, die ich diese woche auf dem plan hatte, und ich denke, dass sie tatsächlich wichtig ist, um die tradeoffs hier fair zu beurteilen – wie vergleicht sich TBV mit DLCs (discreet log contracts), also dem älteren und einfacheren bitcoin-kollateralmodell, das viele leute bereits kennen.
ein DLC ist im kern ein vertrag zwischen zwei parteien. bob und larry einigen sich im voraus auf eine bestimmte menge möglicher ergebnisse; ein oracle signiert später genau das ergebnis, das tatsächlich eingetreten ist. diese signatur bestimmt dann, wie eine vorher vereinbarte bitcoin-auszahlung zwischen ihnen aufgeteilt wird. das gibt es schon länger, es ist relativ einfach nachzuvollziehen, und es ist wirklich hart im einsatz getestet – im vergleich zu etwas wie TBV, das sich noch durch den testnet-prozess bewegt.
also wo liegt der tatsächliche unterschied, was jeweils geleistet werden kann. ein DLC ist grundsätzlich bilateral und in den ergebnissen begrenzt – es sind bob und larry, die sich auf eine feste menge von outcomes einigen, die im voraus festgelegt wird. es funktioniert hervorragend für dinge, die nach einem muster geformt sind wie „ist ereignis X passiert: ja oder nein, dann entsprechend auszahlen“. was es jedoch nicht wirklich kann, ist universelle programmierbarkeit oder zu ermöglichen, dass derselbe bitcoin als kollateral über mehrere verschiedene anwendungen hinweg dient, ohne jedes mal einen brandneuen vertrag neu auszuhandeln.
TBV verfolgt etwas strukturell anderes – kollateral, das über eine breitere defi-landschaft hinweg nutzbar ist (kredite heute, stablecoins/derivate/versicherungen als erwähnte zukunftsrichtungen), verifiziert über beweisen für den tatsächlichen smart-contract-zustand, statt über ein fest vorab zwischen zwei namentlich genannten parteien vereinbartes outcome-set.
ich versuche hier ehrlich zu sein, statt TBV einfach als strikt besser zu pitchen – dass DLCs einfacher und stärker erprobt sind, ist ein echter vorteil, besonders für etwas, das eher eng bilateral ausgerichtet ist. TBV gibt etwas von dieser simplizität zugunsten von allgemeingültigkeit und defi-komponierbarkeit auf. verschiedene werkzeuge, die für unterschiedliche probleme geformt sind, kein strikter upgrade-pfad von dem einen zum anderen.
das ist das komplette set an angles, die ich diese woche aus den docs und dem whitepaper herausgezogen hatte.
#baby $BABY
-@BabylonLabs_io
ein DLC ist im kern ein vertrag zwischen zwei parteien. bob und larry einigen sich im voraus auf eine bestimmte menge möglicher ergebnisse; ein oracle signiert später genau das ergebnis, das tatsächlich eingetreten ist. diese signatur bestimmt dann, wie eine vorher vereinbarte bitcoin-auszahlung zwischen ihnen aufgeteilt wird. das gibt es schon länger, es ist relativ einfach nachzuvollziehen, und es ist wirklich hart im einsatz getestet – im vergleich zu etwas wie TBV, das sich noch durch den testnet-prozess bewegt.
also wo liegt der tatsächliche unterschied, was jeweils geleistet werden kann. ein DLC ist grundsätzlich bilateral und in den ergebnissen begrenzt – es sind bob und larry, die sich auf eine feste menge von outcomes einigen, die im voraus festgelegt wird. es funktioniert hervorragend für dinge, die nach einem muster geformt sind wie „ist ereignis X passiert: ja oder nein, dann entsprechend auszahlen“. was es jedoch nicht wirklich kann, ist universelle programmierbarkeit oder zu ermöglichen, dass derselbe bitcoin als kollateral über mehrere verschiedene anwendungen hinweg dient, ohne jedes mal einen brandneuen vertrag neu auszuhandeln.
TBV verfolgt etwas strukturell anderes – kollateral, das über eine breitere defi-landschaft hinweg nutzbar ist (kredite heute, stablecoins/derivate/versicherungen als erwähnte zukunftsrichtungen), verifiziert über beweisen für den tatsächlichen smart-contract-zustand, statt über ein fest vorab zwischen zwei namentlich genannten parteien vereinbartes outcome-set.
ich versuche hier ehrlich zu sein, statt TBV einfach als strikt besser zu pitchen – dass DLCs einfacher und stärker erprobt sind, ist ein echter vorteil, besonders für etwas, das eher eng bilateral ausgerichtet ist. TBV gibt etwas von dieser simplizität zugunsten von allgemeingültigkeit und defi-komponierbarkeit auf. verschiedene werkzeuge, die für unterschiedliche probleme geformt sind, kein strikter upgrade-pfad von dem einen zum anderen.
das ist das komplette set an angles, die ich diese woche aus den docs und dem whitepaper herausgezogen hatte.
#baby $BABY
-@BabylonLabs_io
