1 dienoraštisNewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressNaujienlaiškiai

Užsiprenumeruokite mūsų naujienlaiškį.

Elektroninio pašto adresas

Mes gerbiame jūsų privatumą

Pagrindinis „Blogas“ Įmonių „Blockchain“

30 „Blockchain“ platformos techniniai veiksniai

Pagrindiniai techniniai aspektai, į kuriuos reikia atsižvelgti renkantis „blockchain“ platformą savo verslo reikmėms. Clemensas Wanas 2020 m. Kovo 5 d. Paskelbta 2020 m. Kovo 5 d.

2

Clemensas Wanas yra „ConsenSys“ sprendimų architektas. Jis rašo 30 seelemons.com sąrašus.

Jei jūsų pasirinkta „blockchain“ platforma yra mažiau susijusi su verslo veiksniais (žr. 30 „Blockchain“ platformos verslo veiksnių), galbūt jūs nagrinėjate keletą techninių aspektų, susijusių su jūsų naudojimo atveju. Šis 30 sąrašas apima konkrečius „blockchain“ klausimus, kurie turėtų būti svarbiausi tikrinant platformą.

„DevOps“ / tinklas / diegimas / protokolas

  1. „Blockchain“ sluoksnio diegimo lankstumas – Ar platforma turi viešą instanciją? Leidimas? Privatus? Hibridas?
  2. Optimalus mazgų skaičius – Kiek mazgų reikia tinklui palaikyti? Po vieną kiekvienam nariui? Ar galiu sąveikauti su tinklu nevykdydamas mazgo?
  3. Konteineriai – Ar platformą galima prijungti ir įdiegti per „Kubernetes“?
  4. Tinklo tapatybės valdymo sluoksnis – Kaip valdomi mazgų ir asmenų leidimai? Ar super vartotojams yra apribojimų? Ar yra visų tinklo šalių šaltinio tinklo žemėlapis (pvz., Į DNS panaši paslauga – ENS Ethereum)?
  5. Sutarimo mechanizmas – Ar sistema pagrįsta darbo įrodymu? Dalies įrodymas? Autoriteto įrodymas? Praėjusio laiko įrodymas? Tai tikriausiai nusprendžia valdymo sąranka ir subjektai, atsižvelgdami į tai, kas yra efektyviausia jūsų naudojimo atveju.
  6. Pranešimai tarp organizacijų – Ar yra atskiri sluoksniai asmeniniams pranešimams siųsti? Ar tai pagrįsta AMQP? TriušisMQ? XMPP? Saugus „Scuttlebutt“?
  7. Operacijų apdorojimo metodika – Kokia veiklos tvarka vyksta kalbant apie sandorių apdorojimą? Kada protokolas nurodo, patvirtina ir vykdo operacijas? „Ethereum“ TX siunčiami į patvirtinančius mazgus, kurie užsako / patvirtina prieš vykdydami ir platindami „teisingą“ bloką. Kordoje TX yra patvirtinami atskirai, nes reikia žinoti mazgus per „Flow Framework“, kol notaras jį pasirašys ir nepaskirstys.
  8. Kriptografija – Kokias bibliotekas naudoja ir palaiko maišos ir parašai? (pvz., secp256k1 – Ethereum)
  9. Kriptografijos pritaikomumas – Ar konkretūs mazgai gali pasirinkti naudoti kitą šifravimo biblioteką, atsižvelgdami į savo regionines saugumo taisykles? (pvz., NIST atitiktis)
  10. Dalijimosi failais metodai – Kiekvienas skaitmeninis turtas turi būti kažkaip teisiškai įtvirtintas per saugomą organizaciją arba kode nurodytą teisinį dokumentą / prozą. Kaip failai yra bendrinami tarp platformos organizacijų? Ar jie išsaugoti toje pačioje platformoje? Ar jie paremti panašiai?
  11. Teisinis inkaravimas – Ar protokole yra įdiegta teisinė proza ​​ar teisinių dokumentų įgyvendinimas (pvz., „OpenLaw“)?
  12. Akivaizdus klastojimas, palyginti su klastojimu – Ar kas nors gali pakeisti jūsų vietinio mazgo būseną ir jos istoriją? Jei kažkaip būtų pašalinta operacija ar būsena, ar viskas būtų nesinchronizuota? Ar nurodytus istorinius duomenis galima pakeisti ar ištrinti ir dėl jų gali susitarti visos šalys??
  13. Operacijų atkūrimas – Kaip mazgas atgauna operacijas? Jei jūsų operacijos nėra visiškai paskirstytos visoms šalims, kokie yra naujausios sutartos versijos atsisiuntimo mechanizmai?
  14. DAO pajėgumai – Ar yra pavyzdžių, kurie atspindi valdymo atsakomybę? Tai gali būti naudinga pakartotinai naudojant tinklą palaikyti balsavimą ir valdymą.

Kūrėjų patirtis / „Stack Applications“ viršus

  1. Taikomoji atsakomybė – Dėl ko turite jaudintis kurdami „stack of stack“ („dapp“) viršų? Ar turite priglobti savo mazgą? Ar jūs taip pat esate atsakingas už atitinkamų „Dapp“ žiniatinklio serverių ir sąsajų diegimą? Kaip vartotojai mokės už jūsų programą?
  2. „Dapp“ sluoksnio diegimas – Remiantis leidimais, kaip išmaniosios sutartys diegiamos tinkle? Asmens (pvz., Adresas įtraukiamas į baltąjį sąrašą)? Pagal mazgą (pvz., LEI tapatybė)? Registruotas subjektas (pvz., Verslo tinklas įtrauktas į tinklą)? Infrastruktūros teikėjas (pvz., „Kaleido Marketplace“)? Ar norint diegti reikia mazgo lygio leidimų?
  3. Protingos sutarties kalbos – Kokia kalba parašyta išmanioji sutartis? Ar jis buvo išbandytas? Ar turi gerą bendruomenę?
  4. Išmaniosios sutarčių bibliotekos ir standartai – Ar yra sutartos saugios bibliotekos / funkcijos (pvz., „OpenZeppelin“), kurios yra prižiūrimos ir tikrinamos? Ar yra plačiai sutarta dėl funkcijų, suderintų su standartais, įgyvendinimo (pvz., ERC-20, ERC-721 ir kt.)?
  5. Protingas sutarties atnaujinimas – Kaip atnaujinamos programos? Ar yra gerai apibrėžti pažangių sutarčių kodo naujinimo modeliai?
  6. Prieiga prie informacinių ir rinkos duomenų – tinkle, kokius turimus orakulus galima iškviesti, norint gauti reikiamą informaciją įvykdytam veiksmui atlikti?
  7. Rekomenduojamas asmenų tapatybės valdymas – Ar viešųjų / privačių raktų poros ir adresai natūraliai reikalauja, kad asmenys išlaikytų savo raktus? Ar tai realiai daroma prielaida, kad tarpininkai priims juos jūsų vardu ir vis tiek turės paskyros valdymą paskirstyti kliento nuostatoms?
  8. Bendraukite programose ar tinkluose – Ar dapp gali paskambinti kitam dapp? Ar galima tinklo / šoninės grandinės nuorodos informaciją iš pririšto tinklo?

Vartotojo valdymas / našumas / privatumas

  1. Operacijų apdorojimo našumas – Kaip greitai galite sudaryti eilę prie operacijų, jas apdoroti (paketais / blokais) ir įsitikinti, kad eilė išvalyta pranešant apie „išsaugotus“?
  2. Operacijų apdorojimo mastelis – Ar sistema sukurta taip, kad būtų moduliuojama (horizontaliai arba vertikaliai), kad būtų palaikomas didesnis apdorojimo greitis?
  3. Kartu vykstantys pokyčiai – Ar yra kliūčių atnaujinti tą pačią sutartį ar likutį kelis kartus, kol turtas yra visiškai pakeistas?
  4. Operacijų paskirstymo našumas – Kada jūsų sandoris atnaujinamas visoms šalims? Ar tada, kai blokas apdorojamas? Po 6 blokų gylių? Užbaigus srautą ir pasirašius visoms šalims?
  5. Daugiasriegis sriegimas – Ar jūsų operacijų apdorojimas ir sutarimas gali būti daugialypis arba suskaidytas keliems tinklo dalyviams ir vis tiek susitarti dėl to paties auksinio šaltinio? Ar jūs suskirstėte skirtingus egzekucijų tipus??
  6. Privatumo mechanizmai, skirti užblokuoti lauką – Ar galite bendrinti konkrečius duomenų saugojimo mechanizmo laukus tik su konkrečiais vartotojais? Ar galite paleisti verslo logiką, kuri lygina lauko reikšmes neatskleisdama informacijos (pvz., Aztec ir ZKsnarks)?
  7. Imtuvų privatumo mechanizmai (konfidencialumas) – Ar galite automatiškai pasukti viešuosius raktus taip, kad galutiniam vartotojui, kuriam siunčiate informaciją, nebūtų galima išspręsti žinomos tapatybės?
  8. Siuntėjų privatumo mechanizmai (operacijų srauto modeliai) – Ar negalite pasidalinti sandoriu su visomis šalimis tais atvejais, kai norite, kad sandorį matytų tik jūsų nurodytos šalys?
Pasitarkite su mūsų „blockchain“ ekspertais

Mūsų pasaulinė sprendimų komanda siūlo „blockchain“ mokymus, strategines konsultavimo, diegimo paslaugas ir partnerystės galimybes. Susisiekite su mumis naujienlaiškiu. Prenumeruokite mūsų naujienlaiškį, kuriame rasite naujausias „Ethereum“ naujienas, įmonės sprendimus, kūrėjų išteklius ir dar daugiau. El. Pašto adresas Išskirtinis turinysPilnas „Blockchain“ verslo tinklų vadovasVadovas

Pilnas „Blockchain“ verslo tinklų vadovas

Tokenizacijos įvadasInternetinis seminaras

Tokenizacijos įvadas

Finansų ateitis Skaitmeninis turtas ir „DeFi“Internetinis seminaras

Finansų ateitis: skaitmeninis turtas ir „DeFi“

Kas yra „Enterprise Ethereum“Internetinis seminaras

Kas yra „Enterprise Ethereum“?

Centriniai bankai ir pinigų ateitisBaltas popierius

Centriniai bankai ir pinigų ateitis

Prekių prekybos finansavimas „Komgo Blockchain“Atvejo studija

„Komgo“: „Blockchain“ prekių prekybai finansuoti

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me