Application décentralisée d'échanges physiques

flowpi

Bonjour j’écris rarement sur les forums mais aujourd’hui je viens posté ceci parce que je pense qu’il y a quelque chose à faire, seulement mes compétences me le permettent pas actuellement. Peut-être que quelqu’un pourra y trouvé une inspiration, ou alors ce système est voué à l’échec. En tout cas il y a forcément des failles, peut-être que vous pourriez en trouver une ?

Voici le système en question, je pense que ça peut être développé sur un Smart Contract sur Ethereum ou autre blockchain:

Application décentralisée d’échange de produits physique

A est l’acheteur, B est le vendeur, O est l’objet à vendre, CRY est la cryptomonnaie utilisée pour l’échange.

C, est un adresse contenant les fonds de la transaction, elle n’appartient ni à A ni à B.

D est la durée de jours maximum que A devra attendre avant de recevoir O cette information est renseignée par B avant l’achat.

Déroulement d’une transaction :
1 : A fais une demande d’achat de O, les informations de la transaction sont stockées dans C, en voici la liste:

-La quantité de CRY nécessaire pour l’achat de O (débitée à l’adresse de A),

-Une caution CT d’un pourcentage fixé par le vendeur (débitée à l’adresse de A)

Le timestamp CD du block actuel
D
Une clé CA que seul A peut tenter de décrypté. B doit être dans l’incapacité de le faire.
Adresse postale OA où O doit être envoyé

Suite à ça, B reçoit la clé de décryptage DCA de CA (mais ne doit pas pouvoir décrypter), deux cas de figures se présentent :
1.1 : B n’envoie pas O, A s’inquiète et clique sur un bouton lui permettant de récupérée sont argent,

deux nouveaux cas de figure se présentent :

86400 = nombre de secondes écoulées en une journée
1.1.1 : Au moment du clique une fonction renvoi le timestamp NOW du dernier block à l’instant T du clique, si ( ( Maths.floor( NOW – CD ) / 86400 ) < D ) alors la demande de remboursement est ignorée car le délai de livraison n’est pas encore atteint.

Sinon :

1.1.2 : si ( ( Maths.floor( NOW – CD ) / 86400 ) >= D ) alors B reçoit une demande de confirmation comme quoi O a bien été envoyé, deux nouveaux cas se présentent :

1.1.2.1 : B contredit A en affirmant que le colis a bien été envoyé, la transaction est bloquée, cela entraînant une boucle infini de contradiction, la transaction se bloque, les CRY sur C sont détruits. Si A mentait et possédait O tout en demandant un remboursement,

sa tentative sera veine car B la refuse, les CRY sont détruits, au final en mentant, A perd CT et B ne gagnera rien. Ce qui évitera toutes tentatives futures. B pouvant fixé la caution, il en demandera plus la prochaine fois, par sécurité, jusqu’à ce qu’un équilibre se créé. Si B n’a aucun intêret à mentir car tant que A ne confirme pas la réception, B ne gagne rien, si la transaction est bloquée B est perdant également.

1.1.2.2 : B donne raison à A et confirme qu’il y a un problème avec la livraison de O, A récupère les CRY disponible sur C ( CT comprise ), la transaction est détruite.

1.2 :B envoi O à OA, il prend soin lors de l’envoi d’inclure la clé DCA dans le colis sur un papier ou tout autre format. A reçoit O, trois nouveaux cas de figure se présentent :
1.2.1 :A n’approuve pas O pour une raison particulière, ex : O est endommagé, est une contre-façon,

n’est pas l’article initialement demandé, etc…

Dans ce cas là les CRY sur C sont détruits, A récupères la moitié de CT le reste est détruit, et B ne sera pas payé. Après une expérience comme celle là, A fera plus attention au description et au caractéristique de O et B sera plus pointilleux sur la livraison, si B tentait d’arnaquer A en envoyant une pomme au lieu d’un ordinateur, A n’approuverait pas et B aurait perdu de l’argent dans la livraison et ne recommencera pas.

1.2.2 :A reçoit bien O, cependant la clé DCA n’a pas été livré avec O. Dans ce cas, A garde l’article, étant dans l’incapacité de confirmer la transaction sans la clé, il indique que la clé n’est pas présente, ce qui lui permettra de récupérer la moitié de sa caution l’autre moitié est détruite, le reste des CRY présent sur C seront détruits, B ne reçevra rien et sera plus organiser la fois suivante.

1.2.3 :A reçoit bien O ainsi que la clé de décryptage, O correspond bien à la description qu’il à vu en ligne, A rentre la clé de décryptage, le système valide la clé et C renvoi CT à A, B reçoit les CRY de C, la transaction est terminée.

Si il y a des incompréhensions sur certains points je peux détaillé un peux plus.
Merci