Le contrat ricardien – Bien choisir son serveur d impression

Le contrat ricardien

Le contrat ricardien

Ian GriggSystemics, Inc.Iang@Iang.org

Abstrait

Description de la valeur numérique pour les systèmes de paiement   n'est pas une tâche triviale.   Méthodes simplistes d'utilisation de nombres ou de pays   codes pour décrire les monnaies et ruban à mesurer   symboles permettant d’émettre des obligations, des actions et d’autres moyens financiers.   instruments rencontrent bientôt des lacunes dans leur   capacité à gérer des demandes dynamiques et divergentes.   Les variations apparemment arbitraires du   les significations des différents instruments sont les meilleures   capturés comme des contrats entre émetteurs et   titulaires.   Ainsi, l'émission numérique d'instruments   peut être considéré comme l’émission de contrats.

Ce document propose que le Contrat   est le problème.   Un formulaire de document est décrit qui englobe les   nature contractuelle inhérente de la situation financière   l'instrument répond encore aux exigences   d'être partie intégrante d'un système de paiement.

Peu de travail a été fait sur la classification et description de la valeur dans le domaine de la cryptographie financière. Ce document présente le contrat ricardien, une méthode pour identifier et décrire les problèmes liés aux instruments financiers comme des contrats [1]. Il a été développé à l'origine par Ian Grigg et Gary Howland dans le cadre du système de paiement Ricardo.

1.1. Les origines

La demande initiale était un système d'échange d'obligations [2]. Pour le commerce, un composante de base est un système de transfert ou de paiement qui reçoit et agit sur instructions de transfert pour déplacer des instruments (espèces, obligations) d’un compte à un autre. Chaque instruction doit donc identifier l'instrument.

Un moyen était nécessaire pour capturer, identifier et décrire les instruments négociés. Il y a des milliers de liens, et potentiellement des millions d'autres instruments qui pourraient être émis et échangés, et chacun a unique caractéristiques qui ne se prêtent pas à compression dans les bases de données. Pour un tel système, les espèces ne sont pas différentes des obligations, et nécessite la même description.

1.2. Le problème

Quand quelqu'un émet une monnaie (ou lien ou part) sur Internet, c'est quoi? Qu'est-ce que le destinataire a?

Peu de systèmes d'émission de valeur (systèmes de paiement) Traitez ces questions correctement. Ils se réfèrent généralement à des unités externes existantes de la monnaie et ranger les bords en vrac dans un Accord de l'utilisateur. Par exemple, Paypal, un émetteur de dollars, repose sur la familiarité du dollar américain définir une grande partie de son offre de services. Les émetteurs d'or s'appuient davantage sur leurs utilisateurs accords comme l'unité de métal est pas si familier.

Pour le trading, cela ne suffit pas faire référence à des références connues et connues, comme chaque instrument est différent de façon minutieuse et ces différences comptent pour les commerçants. Même avec les devises, cependant, l'utilisateur a difficulté à déterminer la sécurité et sécurité d'un dollar par rapport à un autre.

Classification par numéros ou symboles est un point de départ. Presque tous les systèmes d'émission numérique identifier leur problème de base en allouant chiffres ou lettres en tant que devises (par exemple, 840, "USD", "AUG" [3]). Ces systèmes rencontrent des problèmes rapidement.

Un émetteur avec plusieurs devises ou plusieurs émetteurs ayant la même valeur nominale la monnaie soulève des questions difficiles. Un émetteur peut-il avoir deux ou plusieurs unités de dollars? Par exemple, dans ISO3166-1, il y a trois dollars américains différents:     840 / USD (en espèces),     998 / USS (même jour), et     997 / USN (le prochain jour). De même, comment une devise en or numérique ("DGC") différencie son or de celui de un autre émetteur, quand tous sont connus comme "AUG"?

1.3. La solution

Comme les obligations sont, à leur essence, des contrats entre émetteurs et utilisateurs, notre problème réduit à l'un des contrats d'émission. Considérant que d'autres questions avoir contrats, nos issues sont contrats.

Notre innovation consiste à exprimer un instrument émis comme un contrat, et de lier ce contrat dans chaque aspect du système de paiement. Par ce processus, un document de grande envergure utilitaire (lisible par l'utilisateur et le programme) est rédigé et signé numériquement par l'émetteur de l'instrument. Ce document, le Contrat ricardien, constitue la base de la compréhension une question et chaque transaction dans cette question.

Par extension, toutes les questions de valeur, telles que devises, actions, dérivés, systèmes de fidélisation et bons d'achat, peuvent bénéficier de cette approche.

1.4. Structure

Ce document est structuré comme suit. Dans la section 2, nous discutons des approches conventionnelles de identifier et décrire l'émission, et explorer les questions et les doutes entourant ces approches. Ensuite, à la section 3, un modèle permettant d’exprimer la délivrance en tant que un contrat est présenté. Enfin, à la section 4, les remarques finales sont ajoutées.

2.1. Un schéma de première génération

Prenons le cas du pionnier système de caisse numérique, eCash, comme initialement sur le terrain par DigiCash BV. La première monnaie de valeur, émis par Mark Twain Bank des États-Unis, a été identifié avec le numéro 4. Lore dit que le premier système alloué un petit numéro séquentiel à chaque devise. Les systèmes de test avaient déjà acquis 0,1,2,3 et donc 4 était le suivant. Les hypothèses marketing de DigiCash ont ensuite changé supposer un problème par pays. Avec le temps, ce régime a été ajusté pour émettre des devises numérotées après indicatifs internationaux (par exemple, 49 pour l’Allemagne, 61 pour l’Australie). Les lacunes de ce régime sont devenues apparentes, donc un nouveau design a été créé [4]. Un numéro de 32 bits décrivant le problème a été utilisé, sur l'hypothèse pragmatique que ce serait assez grande pour couvrir les éventualités prévisibles.

Pourtant, les souches de un émetteur, une monnaie étaient évidents presque immédiatement. Un schéma plus avancé pourrait utiliser un tuple de (émetteur, devise) décrire un système dans lequel chaque émetteur est habilité dans un certain sens à émettre plusieurs monnaies concurrentes [5]. Il est facile de généraliser ce système en ajoutant éléments supplémentaires au tuple: (émetteur, type, identifiant) tuple [6]. Par exemple, une obligation à coupon zéro émise par le Keiretsu conjoint universel et national qui paie en janvier 2100 pourrait avoir un tuple de (JUNK, zéro, Jan_2100).

2.2. Le problème avec les nombres

Les chiffres comme espace d’identification les instruments numériques sont limitants, et ayant des tuples comme une extension n'est pas vraiment une réponse.

Premièrement, que décrivent-ils?     Dans le cas des systèmes de paiement électroniques,     ils peuvent décrire les devises et les émetteurs.     Est-ce l'un ou les deux, et     Comment généraliser à d'autres aspects?     Deuxièmement, quelle sécurité avons-nous que quoi     est décrit est exact?     Alors que beaucoup peut être accompli simplement     s'appuyant sur la réputation     de l'émetteur, financier     les initiés savent que le     la valeur réelle est exprimée dans le     détail et la fiabilité     de la demande.     Troisièmement, comment sont dérivés les nombres?     Un registre central est-il nécessaire?     ou peut tout émetteur de valeur numérique     acquérir un numéro selon les exigences locales?     Enfin, y a-t-il une limite à l'espace?     Nombre entier tel qu'exprimé dans     les paquets sont généralement limités à     une certaine quantité de bits, tels que 32.     Pour le génie logiciel pratique,     il doit y avoir des limites, mais est-ce que celles-ci     limites besoin de limiter les possibilités d'affaires?

2.3. Le défi du succès

Tout système réussi sera utilisé de différentes manières cela donne l'impression d'être cassé. En tant qu’ingénieurs logiciels, nous devons présenter nos inventions avec l'humilité de outilleurs pour les générations futures de constructeurs, pas comme les bureaucrates qui planifient le zonage l'espace de commerce numérique.

Ce qu'il se passe quand nous avons traversé les premiers adoptants, dominé les mamans et les pops, et la concurrence est se tournant férocement sur notre ensemble de retraités âgés? Imaginez des bonbons à la menthe dans les poches de Des milliards de personnes âgées qui jouent au ralenti. Ou imaginez un monde avec un émetteur de points de fidélité numériques sur chaque parcomètre, ou où les étudiants doivent payer les frais de scolarité avec parts des bénéfices futurs. Nous avons déjà vu des musiciens populaires vendre des obligations soutenues par leur musique [7], et propositions de corrections de bugs logiciels financées par questions sécurisées à des utilisateurs anonymes [8].

2.4. L'obligation à coupon zéro

Considérons l'obligation à coupon zéro, un instrument qui paie un valeur nominale d'une monnaie à une date donnée. le zéro est peut-être le plus simple général instrument financier d'usage courant, et il formé la référence pour notre conception.

Décrire la valeur faciale, la devise de la valeur faciale, et la date d'expiration de ce lien, nous ajouterions des éléments supplémentaires au tuple ci-dessus. Mais ce n'est qu'un début. Dans sa description des euro-obligations, Noel Clarke attend des dizaines ou des centaines de champs [9]. Si on examine juste une de ces caractéristiques, par exemple Options de vente liées à un événement, nous constatons qu'un lien doit décrire que se passe-t-il dans le cas de:

une prise de contrôle hostile ou amicale de l'émetteur, une prise de contrôle par l'émetteur d'une autre partie, une recapitalisation, programme de rachat par l'émetteur        de ses propres actions, ou une répartition des actifs au-dessus d'un        certain pourcentage de la valeur nette de l’émission.

Ces éléments sont étroitement liés à l'instrument en question, mais ils représentent des difficultés à l'architecte logiciel. Nous pouvons faire un certain nombre d'observations.

Tout d’abord, chaque événement n’est pas simple. Aujourd'hui, on peut être capable de chausser la notion de "prise de contrôle hostile ou amicale" en un seul paire nom-valeur, mais cela ne survivrait pas à la scène en évolution de règlement et de litige qui s'applique à de tels événements.

Deuxièmement, il n'y a aucune raison de croire que la liste ci-dessus est complète.

Troisièmement, non seulement il sera difficile de concevoir un seul champ de toute sorte pour faire face avec ceux-ci, ils vont surtout être plein de texte légal.

Considérons un point de vue de la disposition des données. Pour décrire le document qui forme la base d'un lien nous aurons besoin d'une structure arborescente base de données de tuples, au minimum. Plus, cette mise en page ne va travailler que pour un seul instrument, ou un ensemble extrêmement serré, presque fongible des instruments.

2.5. L'argent est roi

Les monnaies, ou les espèces, pourraient être aussi serrées. Après tout, un dollar est un dollar est un dollar. Peut-on décrire l'argent avec un ensemble simple de tuples? Même pour de l'argent, nous soutenons qu'une disposition de les tuples ne suffisent pas.

Prenons le cas d'un dollar numérique émis par une banque. Les dollars numériques seraient des dérivés, souvent appuyés par des dépôts du même montant. Cela peut suffire à des fins de marketing mais il ne survivrait pas à un grave problème financier une analyse.

Comparez ces dollars dérivés à ceux émis par la Réserve fédérale américaine Planche. La Fed n'a pas encore nié l'acceptation de ses notes si présentées avec même, si seulement comme une réclamation sur un autre groupe de même instrument, ou pour des dettes fiscales. Les interprétations radicales mises à part, la La Fed n'a jamais déposé de bilan et reste un pari assez solide.

On ne peut en dire autant de n'importe lequel banque émettrice de dollars dérivés. Ses dollars numériques seraient soutenus par des dépôts avec … la même institution. Une telle banque peut fermer ses portes à tout moment, et, compte tenu de l'histoire du secteur bancaire au 20ème siècle, un analyste devrait prendre cette risque sérieusement. En outre, aux États-Unis au moins, la FDIC a déjà décidé que les fonds ainsi détenus sur un les PC de l'utilisateur sont considérés comme des dépôts non assurés [10].

Cela ne veut pas dire qu'une banque donnée est sur le point de fermer les portes, mais de demander ce qui se passe quand un émetteur fait en effet défaut sur sa promesse?

Tout détenteur d'un actif comportera un risque. Un détenteur de dollars électroniques emportera le risque d'échec de l'émetteur et le titulaire de dollars d'un autre émetteur porte un similaire, comparable, mais distinct risque. Chacun de ces risques entraîne un coût, qui devrait être soustrait de la valeur nominale du dollar à calculer une valeur comparative. C’est dans cette distinction des risques que se situe l’inévitable le fait qu’un dollar donné n’a pas une valeur constante, même par rapport à un dollar bien connu comme celle de la Réserve fédérale.

2.6 Les petits caractères du contrat

S'il n'y a pas un seul dollar, ce qui reste? Clairement, nous devons décrire chaque et chaque dollar pour ce que c'est. Cela semblerait être une tâche de petits caractères et détail, et, en effet,

chaque devise émise distincte est un contrat distinct entre l'émetteur et le titulaire.

Un contrat peut encapsuler le détail. Considérons les contrats de monnaie souverains originaux, dans lequel l'émetteur a promis de payer le porteur en onces de métal précieux. C'est déjà quatre données dans le contrat:   quel souverain,   "payer au porteur"   quoi payer, et   combien de cela.

C’est donc avec chaque obligation, chaque monnaie et tout instrument financier de toute complexité En fait, dans le domaine numérique, la question de comment traiter un instrument financier réduit en grande partie à la façon de traiter un contrat.

Ou un problème est un contrat. Problèmes au sein d'autres systèmes de paiement avoir des contrats mais seulement en tant que complément des documents tels que les contrats d'utilisation. Souvent, leur rôle et leur importance est sujet à des batailles; Commercialisation veut les cacher, alors que légal demande qu'ils soient poussés dans le visage de l'utilisateur à tout moment.

Une fois que nous acceptons que la question est un contrat, la tâche devient simple: créer un contrat qui peut être lié au système de paiement comme pièce maîtresse. C'est le sujet de la section suivante.

Presque tous les aspects des contrats ricardiens sont mieux visibles en examinant des exemples, et cette section couvre brièvement la détails saillants, avant de discuter de la ramifications. Des exemples peuvent être trouvés à

webfunds.org/ricardo/contracts/ .

3.1. Définition

Un contrat ricardien peut être défini comme un seul document qui est a) un contrat offert par un émetteur à ses titulaires, b) pour un droit de valeur détenu par les titulaires,    et géré par l'émetteur, c) facilement lisible par des personnes (comme un contrat sur papier), d) lisible par des programmes (analysable comme une base de données), e) signé numériquement, f) porte les clés et les informations du serveur, et g) associé à un identifiant unique et sécurisé.

Dans les termes les plus simples possibles, un contrat ricardien est un document définissant un type de valeur pour l'émission Sur internet [11]. Il identifie l'émetteur, étant le signataire, et tous les termes et clauses que l'émetteur juge opportun ajouter pour que le document soit considéré comme un contrat.

Le même document doit être lisible par des personnes et analysable par des programmes. Le contrat de Ricardian est formaté en fichier texte qui peut être facilement lu (affiché ou imprimé), et les programmes peuvent le convertir en formes internes pour rechercher des paires nom-valeur. Il comprend une section spéciale pour chaque type contrat, tels que cautionnement, action, devise, etc. D'autres sections dans décrivent, dans programme-parsable termes, utilisation des points décimaux, titres et symboles.

En tant que signataire légal, l'émetteur signe le document sous forme de texte clair OpenPGP avec son contrat clé de signature [12]. Il inclut la chaîne complète de clés OpenPGP dans le document pour permettre aux programmes de directement vérifier et authentifier.

Identifier de manière unique le contrat, tout utilisateur peut calculer un résumé du message canonique sur le document signé. Ce résumé de message est inclus dans tous les enregistrements des transactions, et fournit une sécurité (infalsifiable) lien du document vers le comptabilité de l'émission.

Par exemple., e3b445c2a6d82df81ef46b54d386da23ce8f3775 est le résumé complet du message pour Numéro de prépayé de Systemics Inc dollars de services. Communément appelé hachage, le résumé du message est une technique cryptographique pour créer un nombre relativement petit qui est un à un avec le document. C'est, pour chaque document, il n'y a qu'un hachage, et le Le hachage se réfère uniquement à ce document. L'algorithme est la norme bien connue, SHA1.

3.2. Quelques observations

Les observations suivantes mettent en évidence quelle est la force du résultat.

Limites de hachage ébullition grenouille. Un changement de contrat progressif du plus fort     la fête au fil du temps est connue comme ébullition de grenouille.     La partie la plus forte est généralement l'émetteur,     et peut être prévu de changer le contrat     s'il y a un avantage. C'est une attaque fréquente.     Un résultat de l'utilisation de l'identifiant de hachage     est-ce qu'aucune des parties ne peut changer le contrat     arbitrairement ou subrepticement.

Pour voir cela est vrai, nous devons examiner     les enregistrements qui font référence au hachage.     Une application peut signer tout important     enregistrements (par exemple, paiements, jetons, reçus,     soldes), et ces enregistrements signés     inclure le hash d'un contrat ricardien.     Le hash dans l'enregistrement ne peut pas être changé     sans perdre sa capacité à passer un test de     validité de la signature.     De même, le contrat ne peut être modifié sans     perdre sa relation avec les enregistrements déjà     signé et livré.     En d'autres termes, chaque enregistrement, détenu par chaque utilisateur,     incorpore une copie immuable de ce hachage.     Toute modification du contrat crée un nouveau hachage,     et ce nouveau hash n'est pas celui que les utilisateurs     avoir ou valeur.

Cela cristallise le contrat pour les deux parties,     arrêter le plus fort     partie de modifier le contrat subtilement à     un peu plus tard.     Dans une certaine mesure, cela résout le déséquilibre     de pouvoir entre le fournisseur et le client dans le     offre d'un contrat de formulaire. La petite fête     n’a pas d’option pour négocier, mais le     plus grande partie la possibilité de réclamer un distinct     contrat à une date ultérieure.     La limitation a un coût, car elle peut     être une nuisance pour l'équipe de soutien de cette     instrument financier.

La PKI ricardienne apporte de la clarté. Les contrats ricardiens ont leur propre public     Key Infrastructure ("PKI") avec eux.     La clé publique de niveau supérieur de l'émetteur est incluse dans le     contrat, et il signe sa clé de signature de contrat,     également inclus.     La clé de signature du contrat signe le contrat lui-même.

Ceci réalise plusieurs choses.     Tout d'abord, le logiciel client peut vérifier     l'ensemble de la chaîne de signature numérique     en une séquence automatisée.

Deuxièmement, il n'est pas nécessaire d'avoir un complexe     ICP multipartite. Toutes les clés sont présentes,     et il n'y a pas besoin d'aller les chercher     sur le net.     Ceci élimine les attaques de substitution, par lesquelles     une clé qui pourrait passer des contrôles pourrait être     inséré dans une phase de recherche clé.     Cela réduit également les coûts de façon spectaculaire.

Troisièmement,     le hachage canonique du contrat représente également un     signature sur le contrat. Il est enregistré     dans tous les enregistrements pertinents, et donc enchevêtrement     le contrat avec ces activités [13].     Une fois que le contrat est en jeu depuis un moment,     il établit sa provenance par la présence     et la confiance du public utilisateur. Cela fournit     preuve beaucoup plus convaincante que celle de l'émetteur     la signature elle-même; une fois l'émetteur et le public     ont passé du temps et de l'argent en s'appuyant sur le contrat,     via le hachage, il est difficile pour l'émetteur de renoncer     sur la nature du contrat ou sa signature.

Le résultat est une PKI qui offre une forte     fiabilité de bout en bout, basée sur un seul document.     Ce n'est tout simplement pas présent dans d'autres conceptions pour les ICP [14].     Cette fiabilité est payante dans la résolution des litiges     phase, où, nous suggérons, le contrat de Ricardian     peut rester seul sur ses mérites et ne nécessite aucun     descriptions complexes de la PKI, signatures numériques,     ou des références à des tiers incertains     pour renforcer sa provenance.     En incluant les touches, nous pouvons dessiner quelques     lignes simples dans le contrat, affirmant     "cette clé signe cette clé, et que cette dernière signe le     Contrat. La première clé est la clé de niveau supérieur de     la personne qui a signé ce contrat.     C'est toute l'histoire, mi'lud. "

Validation de la clé de l'émetteur. Tous les bons protocoles de cryptographie se divisent en deux parties, le premier dit au second, "fait confiance à cette clé complètement."

La clé de niveau supérieur de l'émetteur en fin de compte authentifie le contrat. Les clés et d'autres informations dans le contrat permettent également un protocole tel que SOX pour amorcer un connexion fortement sécurisée au serveur [15].

Comment alors vérifier cela cette clé ultime est-elle vraiment celle de l'émetteur? Ce n'est pas difficile. Les affaires processus d'émission numérique implique beaucoup de établissement de relations entre les émetteurs et les utilisateurs. Beaucoup d'interactions différentes impliquer des chances d'établir la confiance. Par exemple, sur son site Web, l’émetteur peut publier le contrat, les clés et les hachages, et que d'autres sites les reflètent. La valeur ainsi émise sera distribuée via des paiements qui incluent le hachage. Une partie déjà de confiance livre habituellement ces paiements. Les paiements identifient valablement le contrat, et dérivent leur propre validité, via le hash.

Comparez cela aux hypothèses de la x.509 PKI derrière la navigation SSL / HTTPS (ce qui suit est très discutable, mais est présenté à titre de comparaison seulement). Dans cette ICP, il a été initialement affirmé qu’un l'utilisateur présenterait sa carte de crédit aux sites avec lequel elle n'avait aucune relation antérieure et aucun moyen pour elle d'établir la provenance de la clé du site. Ainsi, un tiers de confiance, l'autorité de certification, a été mis en place pour confirmer la clé.

Les paiements, les transactions et les questions de finance sont fondamentalement riche en relations. La nature de l'argent et des finances est que les participants font toujours leur propre diligence raisonnable, ils préfèrent écouter des pairs en qui ils ont déjà confiance, et ne pas accepter facilement la parole d'un parti indépendant. Ainsi, il n'y a pas de place pour un tiers central se tenir debout et authentifier les joueurs. Avant que l'utilisateur ne souhaite placer valeur sur un paiement donné, elle a presque certainement été mis au courant du contrat via d'autres moyens.

Présomption de possession. L'utilisation du hash comme identifiant est un compromis comme il est incompréhensible pour l'homme [16]. Pourtant, ce même compromis offre un avantage inattendu: L'utilisation de la question conduit à une présomption     que l'utilisateur a le contrat. Pour utiliser une question de valeur, telle qu'une devise, le     l'utilisateur doit avoir le hachage dans les enregistrements applicables.     Autrement dit, si l'utilisateur reçoit un paiement,     cet enregistrement de paiement inclura le hachage.     Comme le hachage n'est pas descriptif,     cela implique que l'utilisateur a le contrat     afin d'interpréter le problème.

Pour voir que c'est vrai,     imaginez avoir un disque avec le hash     mais sans avoir le contrat.     La première chose que l'utilisateur     aura besoin est une base de données de     paramètres lui disant quoi     le hash fait référence à.     Contrairement à un paiement en 10 GBP,     un paiement de 1000 dans "972097bb …"     n'est pas intelligible.

Mais comment un logiciel pouvait-il prédire quoi     l'utilisateur a besoin de savoir sur le hash?     Très rapidement     il devient évident que le logiciel     vaut mieux stocker la source de     l'information – le contrat complet     lui-même – comme il supprime     un degré de complexité illimité     en stockant intermédiaire ou secondaire     information.

Le logiciel peut toujours fonctionner avec     seulement le hash. Cependant, il     serait complètement aveugle à la     sémantique de l'instrument.     Une telle approche cavalière pourrait être acceptable pour     communications et stockage, mais pour les logiciels utilisateur,     c'est l'équivalent d'un échec traumatique.     Pour y faire face, le côté client     le logiciel prend particulièrement soin de     acquérir et conserver des contrats.     Par conséquent, nous pouvons énoncer la présomption     avec un certain degré de confiance:     dans un système en fonctionnement,     l'utilisateur dispose du     contrat ricardien complet     (bien que sous contrôle logiciel).

Ceci n’est qu’un petit pas pour le logiciel client,     mais est un pas de géant pour la relation     entre l'émetteur et le titulaire. Plus précisément,     ayant une forte présomption que l'utilisateur     a le contrat complet disponible va simplifier     beaucoup juridique     aspects relatifs aux responsabilités de l'émetteur.     (Nous suggérons et reconnaissons ainsi     les ramifications légales du terme présomption,     mais ni l'espace ni l'expertise ne le permettent     plus dans cet article.)

3.3. Les quatre coins de la page

Le contrat ricardien offre une riche source d'informations primaires complètes. L'histoire complète est là sous forme textuelle, en paramètres analysables, et en la chaîne de signature. Ainsi, dans un litige, une attaque légale hostile a moins de place manœuvrer, et ne peut que confirmer les faits comme prévu dans le contrat.

Notre intention est que le contrat soit le début et fin de la discussion; nous appelons ce principe la règle d'un contrat. La fraternité juridique fait référence à "le contrat étant délimité par les quatre coins de la page. " En montrant comment nous avons soigneusement disposer d'un document lisible, avec une signature numérique vérifiable, et un identifiant infalsifiable liant à chaque enregistrement, nous pouvons plus facilement demander à la justice de accepter que le document unique qui est être présenté est en effet le contrat en vigueur convenu entre les parties.

Le contrat est la clé de voûte de l'émission [17]. Notre innovation est d'exprimer tout le saillant les détails d'une émission en tant que contrat infalsifiable, inlassablement lié à chaque action dans un Système de paiement. Dans ce Ainsi, l’innovation financière peut se développer parallèlement les lignes qu'il a toujours fait – au moyen de l'innovation dans les contrats. En traduisant l'institution du contrat dans le domaine numérique, nous construisons sur des siècles et même des millénaires une valeur d'expérience dans la documentation, le partage et contestant le sens des accords entre des soirées.

4.1. Le défi de la complexité

Pour capturer la complexité, nous pouvons mettre des documents tels que contrats sous forme électronique et les signer en utilisant technologies de signature numérique telles que OpenPGP. Le résultat est un analogue raisonnable du papier et des contrats d'encre que la plupart des gens et des entreprises sont familiers avec, renforcés avec cryptographique intégrité.

Avec le hash comme identifiant, le logiciel peut maintenant uniquement identifier un arrangement financier donné et peut confirmer une forte chaîne de signatures. Le hash implique fortement l'utilisateur dispose du contrat à tout moment, et cela ne peut pas être changé sans être remarqué.

Le contrat de Ricardian offre un avantage énorme à l'émetteur – clarté dans de nombreux cas juridiques et clients questions de support. L'utilisateur bénéficie de coûts globaux moins élevés, et une meilleure présentation de l'information, dans un cadre plus cohérent.

4.2. Leçons apprises

Le formulaire est utilisé avec succès depuis 1996. Depuis ce temps, il a livré environ 20 instruments financiers sans échec.

Des disputes. Le contrat ricardien est apparu dans deux forums distincts de litige résolution pour résoudre les réclamations [18]. De façon anecdotique, chaque réclamation a été résolue directement et efficacement, et sans tracas, simplement en se référant à la contrat ricardien applicable.

Automatisation. Relativement peu a besoin d'être automatisé. En pratique, des champs ont été insérés et normalisé afin que les programmes puissent extraire décimalisation (dollars contre cents), étiquettes pour les unités (USD versus $), et titres pour l'émetteur et l'émission. Contrairement aux attentes, il y a n'a pas été demandé d'analyser tous les champs.

Coût. Le coût du concept a été comparé favorablement avec celui engagé avec d'autres systèmes de paiement. La préparation du texte du contrat comporte certains coûts, mais pas plus qu'un contrat d'utilisateur. Configuration requise pour l'infrastructure OpenPGP (clés et signature) ajoute des coûts mineurs à émetteurs, mais ils sont facilement compensés par les avantages de réduction des risques liés à la distribution des contrats. Les éditeurs de signature personnalisés ont contribué à réduire ces coûts [19].

4.3. Défis pour l'avenir

Superposition. La superposition de contrats est un besoin imminent. De nombreuses entreprises peuvent prendre un standard et défini ensemble de termes et s’en inspirer directement. D'autres contrats résultent de contrats antérieurs et besoin de les référencer.

XML. Les premiers efforts suggéraient que XML romprait le règle d'un contrat, mais il semble que nous allons besoin de quelque chose de mieux que l'INI archaïque format [20]. Une proposition récente, le voucher XML, s’arrête à court de se présenter comme un contrat [21].

Loi du contrat. Le traitement du contrat ricardien comme une Contrat peut soulever plus de questions juridiques que de réponses. Par exemple, ce formulaire est-il bien un contrat? Comment différentes juridictions perçoivent-elles la concept (common law, droit civil, UCC, code coranique)? Est-ce un contrat négocié ou un formulaire? Quand l'utilisateur a-t-il accepté le contrat? Quelle est la force de la présomption? que l'utilisateur a le contrat?

Contrats intelligents. En unifiant toutes les informations dans un programme lisible     fichier, il y a le potentiel accru de smart     des contrats [22]. Nous ne sommes pas allés plus loin dans cette direction que des méthodes pour gérer les nombres décimaux. Ceci est en partie dû au manque de demande, et en partie parce qu'il n'est pas clair comment un tribunal traiterait un programme informatique présenté comme un contrat.

[1] Introduit à l'origine dans     Ian Grigg, "Cryptographie financière en 7 couches," 4ème conférence sur la cryptographie financière, Anguilla, 2000,     Springer-Verlag LNCS 1962.     Tous les papiers sont à     http://iang.org/papers/ [2] Ian Grigg, "Trading numérique" Rapport de finance virtuelleNovembre 1997. [3] Codes de pays et de devise, ISO3166-1. [4] Bryce Wilcox,     examen de la conception ouverte, La liste des développeurs de DigiCash, ,     Août 1997. [5] Ibid, Rachel Willmer, 14 août 1997. [6] Robert Hettinga,     " Qu'est-ce qu'un lien au porteur numérique?" e $ rants ,     19 novembre 1995 [7] Alex Tajirian,     " David Bowie Bonds" [8] Ian Grigg et C. Petro, "Utiliser les marchés électroniques pour atteindre     Distribution efficace des tâches, " 1ère conférence sur la cryptographie financière ,     Anguilla, 1997     Springer-Verlag LNCS 1318. [9] Noël Clarke, Guide des euro-obligations,     The Economist Intelligence Unit,     1993. [10] FDIC Avis n ° 8 de l'avocat général; Cartes à valeur stockée, Registre fédéral2 août 1996.     Voir également le communiqué de presse (lisible) intitulé La FDIC continuera de s'appuyer sur l'opinion de l'avocat général     plutôt que d'émettre des règles sur les cartes à valeur stockée,     24 juin 97. [11] Ian Grigg, Guide des contrats ricardiens, WebFonds projet. [12] Jon Callas et al.     "Format de message OpenPGP," Projet Internet,     RFC2440bis (version préliminaire -10). [13] Petros Maniatis, Mary Baker "Sauvegarde historique sécurisée via     Enchevêtrement de la timeline " , 11ème symposium USENIX sur la sécurité,     San Francisco, États-Unis. Août 2002. [14] Jane K. Winn,     " Courriers sans bagages"     49 Revue de droit de la Caroline du Sud 739 (1998) [15] Gary Howland, "Développement d'un système de paiement ouvert et flexible" 1996. [16] Bryce Wilcox, "Noms: décentralisés, sécurisés, ayant un sens humain:     Choisissez deux",     2003 [17] Métaphore de Martin (Hasan) Bramwell.     Voir "Le contrat est la clé de voûte de l'émission" Blog sur la cryptographie financière, 19 septembre 2003. [18] DigiGold v. Systemics,     devant la Cour suprême d'Anguilla (2001),     et ensuite référé à la     Association américaine d'arbitrage (2002). [19] Edwin Woudt,     ContractSignWizard, WebFonds projet. [20] Erwin van der Koogh,     "Contrats ricardiens en XML,"     (présenté à) Ingénierie de cryptographie financière d'Edimbourg (EFCE-2), 2001. [21] Ko Fujimura et Masayuki Terada, Bon XML: Langue du bon générique, Projet Internet. [22] Nick Szabo,     " L'idée des contrats intelligents, "1997.

Click to rate this post! [Total: 0 Average: 0]