Kuidas toimib plokiahelal põhinev detsentraliseeritud sõnumivahetus?

2017. aasta alguses alustasime plokiahelal põhineva sõnumivahetuse [nimi ja link on profiilis] loomist, keskendudes eelistele klassikaliste P2P sõnumivahetajate ees.

On möödunud 2.5 aastat ja me oleme suutnud oma kontseptsiooni kinnitada: praegu on sõnumivahetuse rakendused saadaval iOS, Web PWA, Windows, GNU/Linux, Mac OS ja Android jaoks.

Täna räägime sellest, kuidas plokiahelal põhinev sõnumivahetus töötab ja kuidas kliendirakendused selle API-ga töötavad.


Soovisime, et plokiahel lahendaks klassikaliste P2P sõnumivahetajate turvalisuse ja privaatsuse probleemid:

• Üks klikk konto loomiseks — ei mingeid telefone ja e-posti aadresse, pole juurdepääsu aadressiraamatutele ja geolokatsioonidele.
• Vestluspartnerid ei loo kunagi otseseid ühendusi, kogu suhtlemine toimub jaotatud sõlmede süsteemi kaudu. Kasutajate IP-aadresse ei ole üksteisele nähtavad.
• Kõik sõnumid krüpteeritakse End-to-End curve25519xsalsa20poly1305. Tundub, et see ei üllata kedagi, kuid meie lähtetekst on avatud.
• MITM-rünnakud on välistatud — iga sõnum on tehing ja allkirjastatakse Ed25519 EdDSA-ga.
• Sõnum liigub oma blokki. Blokkide järjestuse ja timestamp järjekorraga ei saa midagi muuta, mis tähendab ka sõnumite järjekorda.
• "Ma ei öelnud seda" ei toimi plokiahela sõnumite puhul.
• Keskset struktuuri, mis kontrollib sõnumi "usaldusväärsust", ei ole. Selle teeb jaotatud sõlmede süsteem konsensuse põhjal, ja see kuulub kasutajatele.
• Tsensuuri puudumine — kontode blokeerimine ja sõnumite kustutamine ei ole võimalik.
• Plokiahela 2FA — alternatiiv hädavajalikule SMS-põhisele 2FA-le, mis on rikkunud palju tervist.
• Võimalus saada kõik oma vestlused igalt seadmel igal hetkel — see tähendab, et ei ole vajadust vestlusi kohapeal salvestada.
• Sõnumite kohaletoimetamise kinnitamine. Mitte kasutaja seadmele, vaid võrku. Põhimõtteliselt on see kinnitamine, et saaja võib teie sõnumit lugeda. See on kasulik funktsioon kriitiliste teadetega saatmiseks.

Plokiahela eeliste hulka kuulub ka tihe integreerimine krüptorahadega nagu Ethereum, Dogecoin, Lisk, Dash, Bitcoin (see on protsessis) ja võimalus saata tokeneid vestlustes. Oleme isegi loonud sisseehitatud krüpto vahetusautomaat.

Edasi liikudes — kuidas see kõik töötab.

Sõnum on tehing

Kõik on juba harjunud, et plokiahelas edastatakse tehingud üle kasutajate vahel (mündid). Nagu bitcoinil. Oleme loonud erilise tüübi tehingute jaoks sõnumite edastamiseks.

Et saata sõnum plokiahela messengeri, tuleb läbida mitu etappi:

1. Šifreerige sõnumi tekst
2. Asetage šifreeritud tekst tehingusse
3. Allkirjastage tehing
4. Saada tehing mis tahes võrgu sõlmele
5. Jaotatud sõlmede süsteem määrab sõnumi "usaldusväärsuse"
6. Kui kõik on korras, lisatakse sõnumitehing järgmisse plokki
7. Saaja ekstraktib sõnumitehingu ja dešifreerib selle

Etapid 1–3 ja 7 teostatakse kohapeal kliendis, etapid 5–6 võrgu sõlmedes.

Sõnumi šifreerimine

Sõnumid šifreeritakse saatja privaatvõtmega ja saaja avaliku võtmega. Avaliku võtme saame võrgust, kuid selleks peab saaja konto olema initsialiseeritud, st tal peab olema vähemalt üks tehing. Võib kasutada REST-päringut GET /api/accounts/getPublicKey?address={ADAMANT address}, ja vestluste laadimisel on kõigi vestlejate avalikud võtmed juba olemas.

Messenger šifreerib sõnumid algoritmiga curve25519xsalsa20poly1305 (NaCl Box). Kuna konto sisaldab Ed25519 võtmeid, tuleb box'i loomise eel need võtmed kõigepealt muuta Curve25519 Diffie-Hellman'iks.

Siin on näide JavaScriptis:

/**
 * Encodes a text message for sending to ADM
 * @param {string} msg message to encode
 * @param {*} recipientPublicKey recipient's public key
 * @param {*} privateKey our private key
 * @returns {{message: string, nonce: string}}
 */
adamant.encodeMessage = function (msg, recipientPublicKey, privateKey) {
  const nonce = Buffer.allocUnsafe(24)
  sodium.randombytes(nonce)

  if (typeof recipientPublicKey === 'string') {
    recipientPublicKey = hexToBytes(recipientPublicKey)
  }

  const plainText = Buffer.from(msg)
  const DHPublicKey = ed2curve.convertPublicKey(recipientPublicKey)
  const DHSecretKey = ed2curve.convertSecretKey(privateKey)

  const encrypted = nacl.box(plainText, nonce, DHPublicKey, DHSecretKey)

  return {
    message: bytesToHex(encrypted),
    nonce: bytesToHex(nonce)
  }
}

Sõnumitehingu loomine

Tehingul on järgmine üldine struktuur:

{
  "id": "15161295239237781653",
  "height": 7585271,
  "blockId": "16391508373936326027",
  "type": 8,
  "block_timestamp": 45182260,
  "timestamp": 45182254,
  "senderPublicKey": "bd39cc708499ae91b937083463fce5e0668c2b37e78df28f69d132fce51d49ed",
  "senderId": "U16023712506749300952",
  "recipientId": "U17653312780572073341",
  "recipientPublicKey": "23d27f616e304ef2046a60b762683b8dabebe0d8fc26e5ecdb1d5f3d291dbe21",
  "amount": 204921300000000,
  "fee": 50000000,
  "signature": "3c8e551f60fedb81e52835c69e8b158eb1b8b3c89a04d3df5adc0d99017ffbcb06a7b16ad76d519f80df019c930960317a67e8d18ab1e85e575c9470000cf607",
  "signatures": [],
  "confirmations": 3660548,
  "asset": {}
}

Sõnumitehingu puhul on kõige olulisem väärtus asset — siia tuleb sõnum paigutada objektis chat sellise struktuuriga:

• message — salvestame šifreeritud sõnumi
• own_message — nonce
• type — sõnumi tüüp

Sõnumid jagunevad samuti tüüpideks. Sisuliselt näitab parameeter type kuidas mõista message. Saame saata lihtsalt teksti või objekti huvitavate elementidega — näiteks tehingud krüptovaluutas vestlustes.

Kokkuvõttes koostame tehingu:

{
  "transaction": {
    "type": 8,
    "amount": 0,
    "senderId": "U12499126640447739963",
    "senderPublicKey": "e9cafb1e7b403c4cf247c94f73ee4cada367fcc130cb3888219a0ba0633230b6",
    "asset": {
      "chat": {
        "message": "cb682accceef92d7cddaaddb787d1184ab5428",
        "own_message": "e7d8f90ddf7d70efe359c3e4ecfb5ed3802297b248eacbd6",
        "type": 1
      }
    },
    "recipientId": "U15677078342684640219",
    "timestamp": 63228087,
    "signature": "siin on allkiri"
  }
}

Tehingu allkiri

Kuna kõik peavad olema veendunud saatja ja saaja, saatmise aja ning sõnumi sisu usaldusväärsuses, allkirjastatakse tehing. Digitaalne allkiri võimaldab kontrollida tehingu autentsust avaliku võtme abil — selle jaoks ei ole vajalik privaatne võti.

Ja siin on allkiri, mis luuakse privaatse võtme abil:

Skeemist nähtub, et tehingu peame esmalt SHA-256 järgi rühmitama ja seejärel allkirjastama. Ed25519 EdDSA ja saame allkirja allkiri, ja tehingu identifikaator on osa SHA-256 räsist.

Näite rakendamine:

1 — Loomine andmeplokist, sealhulgas sõnum

/**
 * Calls `getBytes` based on transaction type
 * @see privateTypes
 * @implements {ByteBuffer}
 * @param {transaction} trs
 * @param {boolean} skipSignature
 * @param {boolean} skipSecondSignature
 * @return {!Array} Contents as an ArrayBuffer.
 * @throws {error} If buffer fails.
 */

adamant.getBytes = function (transaction) {

  ...

  switch (transaction.type) {
    case constants.Transactions.SEND:
      break
    case constants.Transactions.CHAT_MESSAGE:
      assetBytes = this.chatGetBytes(transaction)
      assetSize = assetBytes.length
      break

…

    default:
      alert('Not supported yet')
  }

  var bb = new ByteBuffer(1 + 4 + 32 + 8 + 8 + 64 + 64 + assetSize, true)

  bb.writeByte(transaction.type)
  bb.writeInt(transaction.timestamp)

  ...

  bb.flip()
  var arrayBuffer = new Uint8Array(bb.toArrayBuffer())
  var buffer = []

  for (var i = 0; i < arrayBuffer.length; i++) {
    buffer[i] = arrayBuffer[i]
  }

  return Buffer.from(buffer)
}

2 — SHA-256 arvutamine andmeplokist

/**
 * Creates hash based on transaction bytes.
 * @implements {getBytes}
 * @implements {crypto.createHash}
 * @param {transaction} trs
 * @return {hash} sha256 crypto hash
 */
adamant.getHash = function (trs) {
  return crypto.createHash('sha256').update(this.getBytes(trs)).digest()
}

3 — Tehingu allkirjastamine

adamant.transactionSign = function (trs, keypair) {
  var hash = this.getHash(trs)
  return this.sign(hash, keypair).toString('hex')
}

/**
 * Loob allkirja põhjal räsist ja võtme paarist.
 * @implements {sodium}
 * @param {hash} hash
 * @param {keypair} keypair
 * @return {signature} signature
 *\/ 
adamant.sign = function (hash, keypair) {
  return sodium.crypto_sign_detached(hash, Buffer.from(keypair.privateKey, 'hex'))
}

Tehingu saatmine sõnumiga võrku sõlme

Kuna võrk on detsentraliseeritud, sobib iga sõlm, millel on avatud API. Teeme POST-päringu lõpp-punktile api/transactions:

curl 'api/transactions' -X POST 
  -d 'TX_DATA'

Vastuseks saame tehingu ID tüüpi

{
    "success": true,
    "nodeTimestamp": 63228852,
    "transactionId": "6146865104403680934"
}

Tehingu usaldusväärsuse kontrollimine

Detsentraliseeritud sõlmede süsteem konsensuse alusel määrab tehingu-sõnumi "usaldusväärsuse". Kes ja kellele, millal, kas sõnum ei ole asendatud teisega ning kas saatmise aeg on õigesti märgitud. See on väga oluline plokiahela eelis — puudub kesksüsteem, mis vastutaks kontrollimise eest, ja sõnumite järjestus ning nende sisu ei ole vale.

Esmalt kontrollib üks sõlm usaldusväärsust ja seejärel jagab teistega — kui enamus ütleb, et kõik on korras, siis tehakse tehing järgmisse plokki — see ongi konsensus.

Osaliselt koodi sõlmest, mis vastutab kontrollimise eest, saab vaadata GitHubis — validator.js ja verify.js. Aha, sõlm töötab Node.js-il.

Lisame tehingu sõnumiga plokki

Kui konsensus on saavutatud, siis meie sõnum koos teiste usaldusväärsete tehingutega läheb järgmisse plokki.

Plokid on rangelt järjestatud ning iga järgnev plokk genereeritakse eelneva ploki hash'i baasil.

Oluline on see, et meie sõnum on samuti selles järjestuses ja seda ei saa „liigutada“. Kui plokki satub mitu sõnumit, siis nende järjekord määratakse selon timestamp sõnumite.

Sõnumite lugemine

Messengingirakendus tõmbab plokiahelast tehingud, mis on adresseeritud saajale. Selleks oleme loonud lõpp-punkti api/chatrooms.

Kõik tehingud on kõigile kättesaadavad — on võimalik saada krüpteeritud sõnumeid. Ent nende dekrüpteerida suudab vaid saaja oma privaatse võtmega ja saatja avaliku võtmega:

**
 * Decodes the incoming message
 * @param {any} msg encoded message
 * @param {string} senderPublicKey sender public key
 * @param {string} privateKey our private key
 * @param {any} nonce nonce
 * @returns {string}
 */
adamant.decodeMessage = function (msg, senderPublicKey, privateKey, nonce) {
  if (typeof msg === 'string') {
    msg = hexToBytes(msg)
  }

  if (typeof nonce === 'string') {
    nonce = hexToBytes(nonce)
  }

  if (typeof senderPublicKey === 'string') {
    senderPublicKey = hexToBytes(senderPublicKey)
  }

  if (typeof privateKey === 'string') {
    privateKey = hexToBytes(privateKey)
  }

  const DHPublicKey = ed2curve.convertPublicKey(senderPublicKey)
  const DHSecretKey = ed2curve.convertSecretKey(privateKey)
  const decrypted = nacl.box.open(msg, nonce, DHPublicKey, DHSecretKey)

  return decrypted ? decode(decrypted) : ''
}

Ja mis veel?

Kuna sõnumid toimetatakse sellisel viisil umbes 5 sekundi jooksul — see on aeg, mil uus plokk võrku ilmub — oleme välja töötanud socket-ühenduse klient-node ja node-node. Kui node saab uue tehingu, kontrollib ta selle kehtivust ning edastab teistele node'idele. Tehing on klientmessengeridele kätte saadav juba enne konsensuse saavutamist ja plokki lisamist. Nii toimetame sõnumid koheselt, nagu tavaliselt messengereides.

Aadressiraamatu hoidmiseks oleme teinud KVS — võtme-väärtuse salvestuse — see on veel üks tehingute tüüp, kus asset krüpteeritakse mitte NaCl-box, vaid NaCl-secretbox. Nii salvestab messenger ka teisi andmeid.

Failide/piltide edastamine ja grupivestlused vajavad veel palju tööd. Muidugi, formaadis „kiirelt ja lihtsalt“ saab selle kiiresti „kokku kloppida“, aga me tahame säilitada sama tasemega privaatsust.

Jah, on veel palju, millega tegeleda — ideaalis eeldab reaalne privaatsus, et kasutajad ei ühenduks avalike node'idega, vaid käivitaksid oma. Kuidas teil tundub, kui palju protsente kasutajatest seda teeb? Õige, 0. Osaliselt oleme selle probleemi lahendanud Tor- versiooniga messengeri.

Me oleme tõestanud, et messenger plokiahelal võib eksisteerida. Varasemalt oli ainult üks katse 2012. aastal — bitmessage, mis kukkus läbi suurte sõnumite edastamise aegade, protsessori koormuse ja mobiilirakenduste puudumise tõttu.

Skeptitsism on seotud sellega, et plokiahelal põhinevad sõnumitoojad on ajast ees — inimesed ei ole valmis võtma vastutust oma konto eest, isikliku teabe omamine ei ole veel trendiks, ja tehnoloogia ei võimalda plokiahelal kõrgeid kiireid. Järgmised tulevad välja meie projekti tehniliselt arenenumad analoogid. Te näete.

Allikas: habr.com