Stacks-wallet-web: Unterstützung der Standardmerkmalsdefinition für fungible Token (SIP 010) (z. B. Dezimalstellen)

@psq hat hier auch einen allgemeinen Bedarf an SIP010-Unterstützung im Web-Wallet erwähnt (z. B. Dezimalstellen, Grafiken und Symbole korrekt anzeigen), daher werde ich dieses Thema etwas erweitern.

https://github.com/stacksgov/sips/blob/hstove-feat/sip-10-ft/sips/sip-010/sip-010-fungible-token-standard.md

@markmhx cool!

Können wir die voraussichtliche Ankunftszeit dieser Artikel irgendwie verfolgen? zB wie lange bleibt ein Artikel im Rückstand und wie lange dauert es, bis er sich durch den Kanban bewegt?

Gute Frage. Das überlasse ich @andresgalante

Die vollständige Unterstützung von sip-010-Token in einer Brieftasche (oder dem Explorer) geht wahrscheinlich über die Unterstützung der Anzahl der Dezimalstellen hinaus und zieht das Kunstwerk über das uri und das Symbol. Anstatt sich auf die API-Endpunkte zu verlassen, die Salden für native ft-Token bereitstellen, sollten alle Informationen über den Vertrag abgerufen werden, dh der Saldo über get-balance-of und Überweisungen über die Funktion transfer statt über basierend auf der nativen Klarheitsfunktion.

Andernfalls wird es wahrscheinlich zu Abweichungen kommen, da der Token bei einer Übertragung möglicherweise andere Dinge tun muss (überprüfen Sie, ob er übertragen werden kann für 1 mögliches Beispiel).

Und ein Token verwendet möglicherweise nicht einmal einen nativen ft-Token in seiner Implementierung (siehe flexr für ein Beispiel, auch wenn dies in diesem Fall möglicherweise verbessert werden könnte). Mehr dazu weiter unten.

Als zusätzliche Schwierigkeit ist noch unklar, wie die Wallets im Allgemeinen alle SIP-010-Token finden können, die einer Adresse gehören. Wenn ein solches Token ein natives ft-Token verwendet, kann die Vertragsadresse aus dem abgeleitet werden, was vom Endpunkt Get Account Balances (https://blockstack.github.io/stacks-blockchain-api/#operation/get_account_balance) zurückgegeben wird. In diesem Fall kann die Vertragsadresse aus SP32AEEF6WW5Y0NMJ1S8SBSZDAY8R5J32NBZFPKKZ.micro-nthng::micro-nothing extrahiert werden, indem der Wert links von :: .
Wenn jedoch kein natives Token verwendet wird, muss die Brieftasche möglicherweise die Vertragsadresse des Tokens manuell hinzufügen (wie Sie dies in der Metamaske tun können), um mit dem Token interagieren zu können.

Und ich kann mir einige Fälle vorstellen, in denen ein SIP-010-Token mehr als ein natives Token zur Implementierung erfordern würde. Gehen Sie also nicht davon aus, dass es eine Eins-zu-Eins-Zuordnung zwischen einem SIP-010-Token und nativen Token gibt ...

Hoffentlich hilft dies ... und würde bei Bedarf gerne eines der oben genannten entwickeln.

@philipdesmedt Ich kann die Geschwindigkeit unseres Boards im Moment nicht einschätzen, aber wir können bald mit der Designphase dieser Ausgabe beginnen und arbeiten diese Woche an der Roadmap, um sie gegenüber anderen Aufgaben zu priorisieren.

@psq

Hoffentlich hilft dies ... und würde bei Bedarf gerne eines der oben genannten entwickeln.

Wenn wir die Designs fertig haben, wäre dies jemand, der vielleicht selbst implementieren möchte?

Wenn wir die Designs fertig haben, wäre dies jemand, der vielleicht selbst implementieren möchte?

schlechte Wortwahl, mit "entwickeln" meinte ich bei Bedarf weiter erklären

Wollte einläuten, dass sich dies auf eine mögliche Einführung von xBTC durch Tokensoft auswirkt.

@GinaAbrams freut sich,

Ich denke, dies wirkt sich auf die Einführung jedes fungiblen Tokens aus, es sei denn, Sie starten speziell einen mikrodenominierten Token, denke ich

@GinaAbrams Gibt es bestimmte Aspekte des Standards, die von Tokensoft für den Start erforderlich sind?

bestätigt, dass der Versuch, einen SIP-010-Token aus der Web-Wallet zu übertragen, nicht funktioniert. Fehler mit

Der von Ihnen angegebene Vertrag hat keine transfer Funktion.

wie erwartet, da davon ausgegangen wird, dass die Übertragungsfunktionssignatur unterschiedlich ist.

Außerdem ist die Meldung, die Sie beim Setzen von PostConditions.allow die gleiche wie ein leeres Array von Nachbedingungen mit PostConditions.deny , was verwirrend oder irreführend ist.

Die Meldung, die Sie beim Festlegen von PostConditions.allow erhalten, ist die gleiche wie ein leeres Array von Nachbedingungen mit PostConditions.deny, was verwirrend oder irreführend ist.

Dies scheint ein unabhängiges UX-Problem zu sein, das wir patchen müssen? Wenn ja, macht es etwas dagegen, ein Problem dafür zu eröffnen?

Die Meldung, die Sie beim Festlegen von PostConditions.allow erhalten, ist die gleiche wie ein leeres Array von Nachbedingungen mit PostConditions.deny, was verwirrend oder irreführend ist.

Dies scheint ein unabhängiges UX-Problem zu sein, das wir patchen müssen? Wenn ja, macht es etwas dagegen, ein Problem dafür zu eröffnen?

hinzugefügt als #1120