Mini-Rant über Bitcoin-besicherte Kreditprotokolle, die behaupten, "nicht verwahrend" zu sein und DLCs verwenden. Diese Protokolle sehen auf den ersten Blick gut aus, aber wenn man sich die Mechanik anschaut, wie DLCs tatsächlich funktionieren, stellt sich heraus, dass sie etwas mehr verwahrend anbieten, als beworben... DLCs benötigen ein "neutrales Oracle", um einen Kredit zu entscheiden - das ist ein Oracle, das nicht dazu angeregt wird, das Protokoll auszunutzen und über das keine interessierten Parteien Kontrolle haben (der zweite Teil ist entscheidend). Soweit ich weiß, hat bisher noch niemand ein neutrales Oracle erfolgreich aufgebaut - das ist ein sehr schwer zu lösendes Problem. Die meisten auf DLC basierenden Protokolle fungieren selbst als Oracle, was bedeutet, dass sie die volle Kontrolle darüber haben, ob die Gelder eines Nutzers liquidiert oder zurückgegeben werden. Das ist kaum "nicht verwahrend" oder "vertrauenslos". Das soll nicht heißen, dass diese "gefangenen DLC"-Protokolle eine schlechte Lösung sind - der Markt braucht unterschiedliche Ansätze zur Bitcoin-Liquidität. Aber das ist ein massiver Sicherheitskompromiss, über den die Nutzer im Voraus aufgeklärt werden müssen. Transparenz ist der Schlüssel. Das ist letztendlich der Grund, warum @GraniteBTC auf @Stacks mit sBTC aufgebaut wurde - die ursprüngliche Absicht war, es mit DLCs zu bauen, aber das Oracle-Problem erwies sich als unüberwindbar. Ich würde mich freuen, hier eines Besseren belehrt zu werden, da das tatsächliche Entsperren von DLCs für Bitcoin von Bedeutung wäre. Ich habe nur noch niemanden gesehen, der das Oracle-Problem knacken konnte, also glaube ich es, wenn ich es sehe.