Vaizdas: Krists Luhaers

Žaibas „VS Raiden # 2“: ar galime išspręsti stebėjimo bokštų ir stebėjimo tarnybų privatumo ir mastelio problemas?

Šiame straipsnyje aptarsime įvairius stebėjimo bokštų masto didinimo ir LN ir RDN privatumo pagerinimo metodus.

„Lightning“ ir „Raiden“ serijos:

  1. Skirtumai tarp LN stebėjimo bokštų ir RDN stebėjimo paslaugų.
  2. Mastelio keitimo problemų sprendimai ir jų kompromisai (dabartiniai).
  3. Atskaitingumas ir perspektyvūs verslo modeliai.

Kitos kalbos: 简体 中文

Atskleidimas: Aš turiu BTC, ETH, BCH, RDN ir kitas monetas, tačiau mano portfelis yra labai įvairus, todėl aš neturiu finansinių paskatų pasirinkti bet kurią konkrečią monetą. Tikiuosi pamatyti daug projektų su skirtingais mastelio didinimo sprendimais, kurie konkuruos tarpusavyje, o vartotojai turės laisvę naudoti savo pasirinktą mokėjimo sprendimą. Jei priklausote kitai stovyklai, tai gerai, aš neturiu nieko asmeniško prieš jus ir vis tiek galime bendradarbiauti. Šį straipsnį remia ne biržos ne biržos prekybos platforma „LocalEthereum“.

Įvadas

Pirmiausia norėčiau pasakyti didelę ačiū bendruomenei, nes šį kartą žmonės buvo atviri diskusijai, o ankstesnis straipsnis buvo parodytas 4 porainių pradiniuose puslapiuose su keliomis gražiomis diskusijomis. Tikrai tai įvertink!

r / bitcoin, r / btc, r / ethereum, r / cryptocurrency, r / raidennetwork, r / lightningnetwork

Antra, „Raideno“ stebėjimo paslaugos “nėra galutinis pavadinimas ir ateityje gali būti pakeistos, todėl šiame straipsnyje mes naudosime žodį„ žiūrėjimo bokštai “, kad būtų nurodytas tiek„ Lightning “, tiek„ Raiden “įgyvendinimas, jei nenurodyta kitaip (pvz.,„ LN stebėjimo bokštai “arba„ RDN stebėjimo paslaugos “).

Trečia, jei jūs dar nesate žiūrėjimo bokštų koncepcija, tada aš siūlyčiau perskaityti ankstesnį straipsnį, kuriame mes aptarėme, kodėl laikrodžių bokštai yra būtini grandinės mastui mažinti, kaip jie veikia, kokie yra skirtumai tarp LN ir RDN įgyvendinimai aprašė dvi pagrindines stebėjimo bokštų kategorijas, jų eksploatavimo (ir kapitalo) sąnaudas ir apibūdino pagrindinius mastelio didinimo iššūkius.

Ketvirta, mes vartosime terminus:

  1. orientuotas į verslą - tai žiūrėjimo bokštai, kurie gali susieti visus to paties kanalo ar paskyros padarytus valstybės atnaujinimus
  2. orientuota į privatumą - tai žiūrėjimo bokštai, kurie negali susieti to paties kanalo ar paskyros padarytų būsenos atnaujinimų

Norėdami gauti daugiau informacijos apie šiuos modelius, skaitykite ankstesniame straipsnyje.

Šoninė pastaba: kai kurie žmonės paklausė, kodėl formuluotė yra „verslo VS privatumas“. Na, o verslai bando padidinti savo pajamas ir išgyventi iš konkurencijos. Stebėjimo bokštai, kuriems nerūpi privatumas, turi daugiau būdų padidinti savo pajamas ir sumažinti išlaidas, todėl jie tampa perspektyvesni.

Problemos

Yra 3 pagrindinės stebėjimo bokštų problemos, kurias bendruomenė turi išspręsti prieš plačiai priimdama:

  • Privatumas
  • Mastelio keitimas
  • Atskaitomybė

Šiame straipsnyje apžvelgsime skirtingus privatumo ir mastelio problemų sprendimus ir aptarsime jų trūkumus.

Kaip visada, jums nereikia sutikti su viskuo, kas čia parašyta, vis tiek naudinga perskaityti šį straipsnį, ir nedvejodami dalyvaukite diskusijoje, jei turite ką pasakyti.

Privatumas

Aš tvirtai tikiu, kad laikrodžių bokštai yra „Lightning“ ir „Raiden“ tinklų privatumo kliūtis, nes jei stebėjimo bokštai sugebės susieti operacijas, tada kitos privatumo funkcijos neturi labai reikšmės.

Bendras argumentas yra tas, kad ne grandinė vis tiek yra greitesnė, pigesnė ir privatesnė nei tinklo grandinė. Tokią mąstyseną sunku pasiekti visuotiniu įvaikinimu, nes tikrasis klausimas turėtų būti „ar tai geriau už„ Visa “,„ AliPay “,„ WeChat “,„ PayTM “, ar tai bus kada ir kada?“

Be to, tariamai ne grandinės operacijos nėra labiau privačios, nes vartotojas gali naudoti naują grandinės adresą kiekvienai grandinės operacijai, kuri yra numatytoji daugelio piniginių ir paslaugų, tokių kaip „LocalEthereum“, funkcija, o ne grandinės operacijos bus. susietas tik su vienu grandinės adresu / kanalu.

Pažvelkime į keletą galimų būdų, kaip šiek tiek pagerinti privatumą.

1. „Fuzz“ operacijos laikas

Tinka: LN & RDN

Prieš siųsdamas būsenos atnaujinimą į stebėjimo bokštą, vartotojas gali užmaskuoti operacijos laiką, įvesdamas tam tikrą atsitiktinį atidėjimą (pvz., Kelias sekundes ar minutes). Tai padidins srauto analizės kainą.

Tačiau tai neveiks, jei vartotojo priešinga šalis nedelsdama siųs kanalo atnaujinimus į savo sargybos bokštą, nes greičiausiai bus didelis paklusnių stebėtojų bokštų tinklas, kuris dalyvaus masinėje finansinėje priežiūroje, kad atitiktų vietinius ir tarptautinius reikalavimus. įstatymai, kaip ir bankai bei kitos finansų įstaigos, privalo valdžios institucijoms atskleisti visą informaciją apie savo klientus. Priversti tam tikrą delsimą protokolo lygiu gali padėti sušvelninti šią problemą, tačiau tai bus gana keistas žingsnis.

Priminimas: kurdami verslą, laikrodžių bokštai žino, kurį kanalą jie stebi, todėl žino visas kiekvieno kanalo šalis.

Čia pavaizduota, kaip Bobas nedelsdamas siunčia savo valstybės atnaujinimus, o Alisa bando užmaskuoti operacijos laiką:

Be to, atidėti būsenos atnaujinimą ilgesniam laikui (pvz., Kelioms valandoms) yra labai prastas UX, nes norėdamas užtikrinti operaciją, vartotojas turi būti internete, kol bus išsiųstas būsenos atnaujinimas ir vartotojas gaus patvirtinimą. Todėl vis tiek bus gana lengva nustatyti vartotojo laiko juostą ir identifikuoti vartotoją, jei jis turi unikalų pirštų atspaudą ar dažnai keičia laiko juostą.

Šalutinė pastaba: klaidinantis operacijos laikas gali padidinti privatumą užtikrinančių stebėjimo bokštų, kurie negali susieti to paties kanalo ar paskyros būsenų atnaujinimus, privatumą. Tačiau vis dar neaišku, ar į privatumą orientuotų stebėjimo bokštų mastelis gali didėti dėl nuolat augančių veiklos poreikių ir ribotų pajamų gavimo mechanizmų.

Pirkite ir parduokite eterį (ETH), nukreiptą į privatumą užtikrinančią vienakryptį savitarnos saugumą užšifruotoje „LocalEthereum“ prekyvietėje. Galite sukurti naują slaptažodžiu apsaugotą sąskaitą arba prisijungti naudodami mėgstamą piniginę, pvz., „Ledger“, „MetaMask“, arba programas mobiliesiems, pvz., „ImToken“.

Esate tinklaraštininkas ar „YouTuber“? Tada tapkite partneriu ir pradėkite uždirbti nukreipdami naujus vartotojus.

2. Sukite būsenos atnaujinimus tarp skirtingų stebėjimo bokštų

Tinka: LN

Vartotojas gali pasukti kelis stebėjimo bokštus, atsitiktinai atsiųsdamas savo naujų būsenų atnaujinimus į vieną iš jų po kiekvienos ne grandinės operacijos.

Apskritai, tai yra maloni savybė, tačiau ji nepadarys žymiai padidėjusio privatumo šiuolaikiniame pasaulyje, nes turėtume traktuoti kelis stebėjimo bokštus kaip vieną didelį subjektą, stebintį visą tinklo veiklą.

Kaip jau minėta aukščiau, greičiausiai bus didelis paklusnių budėtojų tinklas, kuris, kaip ir bankai, dalyvaus masinėje finansinėje stebėsenoje. Kai kurie stebėjimo bokštai gali pradėti veikti kaip nepriklausomi subjektai, tačiau ilgainiui jų laikysis, kaip neseniai nutiko „ShapeShift“ ir kitose kriptovaliutų biržose.

Šaltinis: @bitconner

Be to, stebėjimo bokštų pasukimas sumažina UX, nes vartotojas turi surasti ir kažkaip sumokėti keliems stebėjimo bokštams. Dauguma pasauliečių patogumui naudos tik vieną populiarų laikrodžių bokštą, todėl pasukimas yra įrankis mažam procentui geinų, nes numatytieji nustatymai yra svarbūs.

Galime priversti naudoti kelis stebėjimo bokštus protokolo lygiu, tačiau tada dideli stebėjimo bokštai tiesiog teiks paslaugą, kad būtų suklastotas kelių žiūrėjimo bokštų naudojimas.

Atminkite, kad šis sprendimas neveiks dabartinio RDN projekto, nes vartotojai viešosiose pokalbių svetainėse siunčia būsenos naujinius visoms registruotoms stebėjimo paslaugoms.

Yra ir kitų būdų, kuriuose taip pat naudojami keli stebėjimo bokštai (pvz., „Celer Network“), tačiau apie juos kalbėsime šiek tiek vėliau.

3. Surinkite įvairių būsenų atnaujinimus

Tinka: LN (jei eltoo, tada ribotos lengvatos) ir RDN (ribotos lengvatos)

Kitas būdas yra panaudoti monetų sujungimo paslaugų sąvoką.

„CoinJoin“ yra nepatikimas būdas sujungti kelis „Bitcoin“ mokėjimus iš kelių lėšų gavėjų į vieną operaciją, kad išorinėms šalims būtų sunkiau nustatyti, kuris „Spender“ sumokėjo kuriam gavėjui ar gavėjams. (wiki)

Panašiai kaip ir prisijungimo prie monetų paslaugos, įvairių vartotojų būsimi atnaujinimai gali būti teoriškai sugrupuoti ir nepatikimai sujungti, o paskui perduoti vienoje duomenų bazėje į stebėjimo bokštą.

Iššūkiai:

  • Neaišku, kaip gali atrodyti nepatikimas įgyvendinimas. Greičiausiai vartotojas vis tiek turės pasitikėti kita šalimi, kurią gali priversti sudaryti slaptą susitarimą.
  • Įdiegimas gali turėti prastą UX, jei vartotojas turės likti prisijungęs, kol gaus patvirtinimą, kad stebėjimo bokštas sėkmingai gavo valstybės atnaujinimą.
  • Ši funkcija turėtų būti numatytasis nustatymas, kitaip pasauliečiai jos nenaudos.
  • Versliniams projektams (pvz., Dabartiniam RDN metodui) bus panaikintas tik operacijos laikas, bet ne valstybės atnaujinimo savininkas.

4. Būsenos atnaujinimų maršrutas

Tinka: LN (jei eltoo, tada ribotos lengvatos) ir RDN (ribotos lengvatos)

Kitas labai įdomus būdas yra siųsti stebėjimo bokštams būsimus atnaujinimus per apynius, panašius į tai, kaip veikia maršrutas.

Tačiau yra daug iššūkių:

  • Alisa turėtų sugebėti nusiųsti užšifruotą paketą per Bobą ir Carolą į laikrodžio bokštą (naudojant „Tor“ bus užmaskuotas tik IP, taigi to nepakanka). Idealiu atveju visi valstybės atnaujinimai turėtų atrodyti taip, kaip jie priklauso paskutiniam apyniui (Carol).
  • Karolis turėtų kažkaip sugebėti sumokėti už sargybos bokšto paslaugą Alisos vardu už Alisos valstybės atnaujinimą, jei laikrodžių bokštai ims mokestį už saugomus ar gautus valstybės atnaujinimus (daugiau apie verslo modelius kitame straipsnyje).
  • Bobui ir Karoliui turėtų būti suteikta galimybė gauti tam tikrus mokesčius už Alisos duomenų perdavimą, siekiant paskatinti juos teikti šias paslaugas.
  • Alisa turėtų gauti patvirtinimą, kad stebėjimo bokštas gavo valstybės atnaujinimą.
  • Tokio pobūdžio maršrutas neturėtų būti patikimas, todėl įgyvendinimas yra labai neaiškus.
  • Ši funkcija turėtų būti numatytasis nustatymas, kitaip pasauliečiai jos nenaudos.
  • Net tinkamai įdiegus, jis sumažins UX, padidins išpuolių platintojus ir pridės daugiau viduriniosios grandies vyrų, kurie ims mokesčius.
  • Į verslą orientuoti stebėjimo bokštai, kurie žino, kuris tikslus kanalas yra stebimas (pvz., Dabartinis RDN požiūris), vis tiek žinos tikrąjį valstybės atnaujinimo savininką, todėl bus panaikintas tik operacijos laikas.

5. Sukurkite daug triukšmo (padirbtas maršrutas)

Kostiumai: LN & RDN (be PFS)

Vartotojas gali bandyti užmaskuoti savo tikras operacijas, siųsdamas daugybę suklastotų centų operacijų arba siųsdamas netikrus būsenos atnaujinimus stebėjimo bokštams, imituodamas didelę ekonominę veiklą ar nukreipdamas maršrutus.

Problemos:

  • Dar daugiau būsenos atnaujinimų turi būti saugomi į privatumą orientuotuose stebėjimo bokštuose, todėl kyla klausimas dėl mastelio keitimo. Stebėjimo bokštai gali bandyti apmokestinti vartotojus už saugomus valstybės atnaujinimus tam tikru į privatumą orientuotu metodu (kuris iš jų?), Tačiau tada pasauliečiai nenaudos šios privatumo funkcijos, nes tai kainuos papildomų pinigų.
  • Sukūrus daug suklastotų operacijų, žymiai padidės pralaidumo pralaidumas, todėl kyla abejonių dėl mastelio padidėjimo.
  • Jei kita šalis naudojasi kelio nustatymo paslauga (PFS), tada nėra prasmės forsuoti operacijas, nes PFS žinos, kurios operacijos buvo tikros.

Taigi ar yra realių naudojimo atvejų?

Na, o į verslą orientuotų stebėjimo bokštų (RDN ar „eltoo“) privatumas gali būti pagerintas, verčiant vartotojus siųsti nedidelio masto triukšmo operacijas protokolo lygiu, iš esmės nepadidėjus duomenų saugojimo reikalavimams, nes stebėjimo bokštai galės laikyti tik naujausi valstybės atnaujinimai. Našumas pralaidumo srityje vis dar išlieka problema, o kita šalis naudodamasi kelio nustatymo paslaugomis pašalins triukšmo pranašumus.

Mintys apie privatumo ypatybes

Tai nėra galutinis sprendimas iki šiol, o visi aukščiau aprašyti metodai turi savo trūkumų ir yra daugiau kaip papildomos savybės siekiant pagerinti privatumą, jei baziniame lygmenyje jau turime aukštą privatumo lygį. Tačiau jei bazinio lygio stebėjimo bokštai galės susieti visus to paties kanalo ar paskyros padarytus valstybės atnaujinimus, tada mes negalime padaryti nieko, kad žymiai pagerintume privatumą.

Mastelio keitimas

Jei LN netaps labai centralizuotu garsiakalbių tinklu, kiekvienoje operacijoje bus keli apyniai, todėl keli mazgai siųs būsenos atnaujinimus stebėjimo bokštams kiekvienai atskirai operacijai.

Kvadratinis augimas. Šaltinis: Ar gali būti stebėjimo bokštų mastelis?

Į privatumą orientuotų stebėjimo bokštų, kurie negali susieti to paties kanalo ar paskyros būsenų atnaujinimų, saugomų duomenų kiekis padidės keturiomis dalimis.

Pažvelkime į įvairius sprendimus ir jų kompromisus.

1. Saugokite tik naujausius valstybės atnaujinimus (į verslą orientuotas modelis)

Tinka: LN („eltoo“) ir RDN (dabartinis įgyvendinimas)

Paprasčiausias sprendimas yra susieti visus valstybės atnaujinimus, kurie buvo atlikti tuo pačiu kanalu ar paskyra, ir saugoti tik naujausius atnaujinimus (balanso įrodymai). Mes tai pavadinome „į verslą orientuotu požiūriu“ ir apie tai galite perskaityti daugiau ankstesniame straipsnyje.

Viskas gali keistis, tačiau dabartinis RDN stebėjimo paslaugų dizainas laikomasi šio požiūrio, o LN stebėjimo bokštai bus finansiškai skatinami pereiti prie šio modelio įdiegus „eltoo“, kuriam reikia aktyvuoti BIP 118, kuris gali būti įdiegtas kartu su „schnorr“, nes abiem atvejais reikia „seguito“ scenarijaus įrašymo, pasak Christian Decker.

Į verslą orientuotas modelis yra lengvesnis, nes jis leidžia stebėtojams atsikratyti didžiulės duomenų bazės ir sutelkti dėmesį į pralaidumo pralaidumo didinimą. Be to, stebėjimo bokštai galės įdiegti sąskaitomis pagrįstą sistemą, kuri yra pats perspektyviausias verslo modelis.

Deja, toks požiūris reiškia labai žemą privatumo lygį, nes stebėjimo bokštai galės visas operacijas susieti su tam tikrais kanalais, adresais, mokamomis sąskaitomis ir tt. Iš esmės tai yra panašu į tai, kaip veikia dauguma „fiat“ pagrįstų centralizuotų mokėjimo sistemų.

2. Nesiųskite būsenos atnaujinimų, kurie vartotojui skiria daugiausia lėšų

Tinka: LN & RDN

Vartotojui nereikia siųsti į stebėjimo bokšto būsenos atnaujinimus, kurie skiria visas ar didžiąją dalį lėšų sau, nes jo priešinga šalis negalės pavogti jokių pinigų iš vartotojo, turinčio šias būsenas, arba kita šalis turės labai blogas sukčiavimo rizikos ir naudos santykis, pvz rizikuojate gauti 90 USD, kad gautumėte 10 USD, todėl vartotojui yra per brangu mokėti už stebėjimo bokštą už šių valstybės atnaujinimų saugojimą, nes pinigų praradimo rizika yra labai maža.

Šis metodas padės 5–20 proc. Sutvarkyti saugomų būsenų duomenų bazes, tačiau tai sukels tam tikrą saugumo riziką ir pernelyg komplikuos UX, nes vartotojas turėtų turėti galimybę koreguoti parametrus saugumo sumetimais. Be to, pasauliečiai, norėdami sutaupyti pinigų, gali suklaidinti nustatymus, o kartu rimtai sumažinti saugumą.

Papildoma: kiekvienas vartotojas vis tiek turi nusiųsti į stebėjimo bokštą bent kelis valstybės atnaujinimus, kurie sau skiria daugiausia lėšų, kad būtų išvengta situacijų, kai apgaulinga sėkmė siekia beveik 100 proc., Nes niekam nerūpi valstybės atnaujinimai, kurie skiria daugiausiai lėšų sau (žaidimo teorija). .

3. Po tam tikro laiko (pvz., Po 1 metų) ištrinkite būsenų atnaujinimus.

Tinka: LN (ne eltoo)

Net ir uždarius kanalą, į privatumą žiūrintys bokštai vis tiek turi saugoti visus valstybės atnaujinimus, gautus iš to kanalo savininko, o tai yra visiškai nepraktiška.

Vienas iš sprendimų yra tas, kad stebėjimo bokštai ištrins senus valstybės atnaujinimus (pvz., Senesnius nei 1 metai), o klientai bus atsakingi už vis dar atidarytų kanalų atnaujinimus.

Deja, šis sprendimas ištrins tik jau uždarytų kanalų būsimus atnaujinimus, todėl jis reikšmingai nesumažins duomenų bazės, nes dauguma kanalų bus uždaromi retai, nebent tam bus rimtų finansinių paskatų. Atminkite, kad bet kokios paskatos uždaryti senus „sunkius“ kanalus padidins spaudimą grandinėje ir greičiausiai apims prenumeratos pagrįstas sistemas, kurių privatumas yra žemas.

Šis sprendimas, kaip pagrindinis kompromisas, sumažins UX, nes vartotojai turės saugoti senas valstijas ir išsiųsti jas pasibaigus galiojimo laikui. Be to, šis požiūris pateiks skirtingus masinio sukčiavimo scenarijus, pvz .:

Bobas pametė telefoną (arba pateko į kalėjimą / komą / pan.). Jis vis dar gali susigrąžinti savo lėšas grandinėje, naudodamas atkūrimo pradmenis, tačiau jis neturi paskutinių valstijų, kad uždarytų savo kanalus, todėl jis turi laukti, kol jo kolegos vienašališkai uždarys visus kanalus, žinodami, kad stebėjimo bokštai užkirs kelią bet kokie bandymai apgauti. Deja, po 1 metų visi jo būsenos atnaujinimai bus ištrinti iš stebėjimo bokšto duomenų bazės, todėl dideli centrai gali laukti ir tada apgauti-uždaryti neaktyvius kanalus (daugiau nei vienerius metus), turėdami labai gerą rizikos ir naudos santykį, pvz. rizikuok 10 USD, kad gautum 100 USD. Žinoma, Bobas gali bandyti atkurti savo ankstesnes būsenas iš stebėjimo bokštų ir po kurio laiko jas dar kartą išsiųsti, tačiau būsenos atnaujinimų gavimas reiškia kažkokią sąskaitomis pagrįstą sistemą, kurios privatumas yra žemas. Bobas taip pat gali kurti visų savo būsimų duomenų saugyklų atsarginių kopijų kopijas po kiekvieno ne grandinės operacijos, tačiau dėl privatumo taip pat yra daug abejonių.

4. Ištrinkite senas būsenas su vartotojo užklausomis

Tinka: LN (ne eltoo)

Kitas sprendimas galėtų būti tai, kad uždarius kanalą, vartotojas nusiųs užklausą į stebėjimo bokštą su ankstesnių būsenų atnaujinimų, kuriuos galima saugiai ištrinti, sąrašu. Jis netgi gali padalinti visus raktus į keletą užklausų per tam tikrą laiką ir nukreipti juos per „Tor“, kad būtų daugiau privatumo.

Šis požiūris gali padėti laikrodžių bokštams šiek tiek sutvarkyti savo duomenų bazes, tačiau vis dar yra daug problemų:

  • Vartotojai turi būti finansiškai skatinami uždaryti senus „sunkius“ kanalus ir siųsti prašymus ištrinti senus valstybės atnaujinimus, taigi bus sudėtinga sąskaitomis pagrįsta pajamų iš mažo privatumo sistema, kuri vartotojams ims periodinius mokesčius, atsižvelgiant į tai, kiek valstybių jie saugo. . Pvz., Vartotojai gali ištrinti didžiąją dalį savo tweets prieš kelerius metus, kurie niekad nebuvo rodomi ir nebeturi didelės vertės, tačiau dauguma vartotojų to nedaro. Kodėl? Nes jie nėra finansiškai skatinami tai daryti.
  • Tarkime, kad vartotojas turi mokėti periodinius mokesčius už visus saugomus būsenos atnaujinimus. Ką daryti, jei vartotojas pametė savo įrenginį su visomis ankstesnėmis būsenomis? Jis tikrai gali susigrąžinti savo lėšas iš atkūrimo sėklos (jei jis parems savo 12–24 žodžius), tačiau jis negalės pateikti stebėjimo bokštui prašymo ištrinti ankstesnes valstybes, net jei visus kanalus galiausiai uždarys jo kanalai. priešingos šalys. Taigi jis turi persikelti į kitą sargybos bokštą arba sukurti naują sąskaitą tame pačiame stebėjimo bokšte, tačiau kadangi pats negali uždaryti kanalų, jis vis tiek turi sumokėti visus mokesčius už senosios sargybos bokšto sąskaitą, kol visi jo kanalai bus uždaryti kitomis šalimis. , kuris gali užtrukti ilgai.
  • Net tinkamai įdiegus, jis neišspręs visų problemų, nes bus ištrinti tik uždarų kanalų būsenos atnaujinimai, todėl stebėjimo bokštai vis tiek turės saugoti visus visų atvirų kanalų būsenos atnaujinimus.
  • Be to, ši funkcija padidins spaudimą grandinėje, nes vartotojai dažniau uždarys ir atidarys savo kanalus.

5. Technologinė pažanga

Šiuo metu galima pamanyti, kad į privatumą orientuoti žiūrėjimo bokštai pasmerkti žlugti, tačiau neturėtume pamiršti apie technologinę pažangą.

Technologija gali kompensuoti mažėjančios grąžos įstatymą, teikdama efektyvesnę aparatinę / programinę įrangą už tą pačią kainą, ir taip sumažinti veiklos sąnaudas. Tačiau kvadratinį veiklos poreikių augimą reikėtų pakeisti linijiniu augimu, kitaip naujovės gali neatsilikti nuo nuolat augančių veiklos poreikių.

Linijinis augimas. Šaltinis: Ar gali būti stebėjimo bokštų mastelis?

Deja, norėdami tai padaryti, norėdami užtikrinti privatumą užtikrinantį apžvalgos bokštą, turėsite apriboti savo vartotojų bazę, įvesdami į sąskaitą pagrįstą sistemą, kurios privatumas yra labai žemas, todėl esame tarsi užstrigę.

Apibendrinkime:

  • Stebėjimo bokštai gali įdiegti sąskaitomis pagrįstą sistemą
  • Apribokite jos vartotojų bazę (pvz., Daugiausia 100 000 vartotojų)
  • Duomenų saugojimo reikalavimai didės tiesiškai
  • Atnaujinkite aparatinę įrangą (pvz., Kasmet), kad eksploatavimo išlaidos išliktų mažos
  • Kartais bus atnaujinama programinė įranga, kad būtų sumažintos veiklos išlaidos

Bet tada kokia yra į privatumą orientuoto požiūrio į valstybės atnaujinimų tvarkymą prasmė, jei bus sąskaita pagrįsta sistema, kurios privatumas yra žemas?

Taigi ar viskas yra blogai, ar yra geresnių sprendimų?

Hibridiniai modeliai

Pažvelkime į kai kuriuos hibridinius modelius, kuriuose derinami skirtingi požiūriai.

1. Apriboti gaunamų būsenos atnaujinimų kiekį

Tinka: LN

Aukščiau mes aptarėme, kad į privatumą nukreiptas apžvalgos bokštas gali pakeisti kvadratinį veiklos poreikių augimą linijiniu augimu, ribodamas savo vartotojų bazę, įvesdamas sąskaitomis pagrįstą sistemą, kurios privatumas yra žemas.

Tačiau yra ir kitas, labiau į privatumą orientuotas būdas apriboti vis didėjančius duomenų saugojimo reikalavimus: paprasčiausiai nebegaukite daugiau vartotojo atnaujinimų iš jokio vartotojo ar nustatykite dienos / mėnesio limitą visiems klientams.

Gali būti bent du skirtingi diegimai:

  • arba vartotojas prideda stebėjimo bokštą kiekvienam naujam būsenos atnaujinimui
  • arba vartotojas inicijuoja seansą ir užsako keletą „laiko tarpsnių“, kuriuos vėliau gali užpildyti būsenos atnaujinimais

Jei budėjimo bokštas atsisako gauti daugiau būsenos atnaujinimų, tada vartotojas bando nusiųsti savo būsenos atnaujinimus į kitą laikrodžio bokštą.

Tai yra įdomus požiūris, kuris stebėtojams suteiks galimybę apriboti savo veiklos sąnaudas, tačiau yra problemų dėl atskaitomybės, UX ir pinigų gavimo, nes sąskaita pagrįsta sistema yra pats perspektyviausias modelis, apie kurį kalbėsime kitame straipsnyje.

Šis hibridinis modelis gali būti išplėstas naudojant tokias papildomas funkcijas kaip:

  • Vartotojas gali siųsti prašymą ištrinti senus būsenų atnaujinimus, kurie priklauso uždariems kanalams (jau aprašyti aukščiau).
  • Vartotojui nereikia siųsti tų būsenų, kurios paskyrė visas ar didžiąją dalį lėšų vartotojui (jau aprašytos aukščiau).

Papildoma: ribojant gaunamų būsenos atnaujinimų kiekį, atskiriems stebėtojams bus suteikta galimybė apriboti jų eksploatavimo išlaidų augimą, tačiau tai neišspręs visos sistemos atminties talpos padidėjimo kvadratiniu būdu problemos, ty kiti stebėjimo bokštai dalinsis našta.

2. Įrašymo mygtukas

Tinka: LN & RDN (ribotos lengvatos)

Vartotojas gali atlikti kelis ne grandinės sandorius nesinchronizuodamas su savo stebėjimo bokštu, o tada siųsti tik naujausią būsenos atnaujinimą, darant prielaidą, kad stebėjimo bokšte reikia saugoti tik naujausią būsenos atnaujinimą, kad sustabdytų galimą priešininką nuo apgaulės (RDN ar „eltoo“ požiūriai). ).

Valstybių atnaujinimai gali būti siunčiami į stebėjimo bokštą:

  • Kai vartotojas paspaudžia mygtuką „išsaugoti / sinchronizuoti“
  • Periodiškai (pvz., Kiekvieną dieną arba valandą, jei buvo kokių nors operacijų)
  • Automatinis sinchronizavimas prieš vartotojui atsijungus

Tokiu būdu į verslą orientuoti stebėjimo bokštai turės daug mažiau informacijos apie vartotojo ekonominę veiklą, pvz., Laiką ir bendrą operacijų sumą, taigi bus tam tikras privatumo laipsnis. Duomenų saugojimo reikalavimai taip pat nebus kliūtis mastelio didinimui, nes sargybos bokštai saugos tik naujausius valstybės atnaujinimus. Be to, pralaidumo pralaidumas bus mažesnis, nes ne visi būsenos atnaujinimai bus siunčiami stebėjimo bokštams.

Problemos:

  • Didžiausia problema yra UX, nes vartotojai turės rankiniu būdu „išsaugoti“ būsenas.
  • Be to, jis nėra toks saugus, nes automatinio sinchronizavimo metu nepavyksta išsaugoti būsenų prieš vartotojui prarandant duomenis ar įrenginį.
  • Automatinis sinchronizavimas parodys vartotojo internetinį tvarkaraštį.
  • Esant dabartiniam RDN dizainui, šis požiūris užmaskuos tik operacijų laiką, nes RDN stebėjimo tarnyba vis tiek matys bendrą operacijų sumą, nes kiekviename pakete bus nonse, nurodančiame bendrą visų operacijų skaičių kanalą.
  • Tai turėtų būti numatytasis nustatymas, kitaip pasauliečiai jo nenaudos.

3. Į privatumą orientuotas modelis su vartotojo prašymais ištrinti senas būsenas

Kostiumai: LN (eltoo)

Įdiegę „eltoo“, net į privatumą nukreipti stebėjimo bokštai galės saugoti tik naujausius tam tikro kanalo būsenos atnaujinimus, tačiau kaip jie gali nustatyti, kurie senų būsenos naujinimai yra seni? Priminimas: į privatumą nukreipti stebėjimo bokštai negali susieti visų būsenų atnaujinimų, kurie buvo atlikti to paties kanalo ar paskyros.

Sprendimas yra finansiškai paskatinti vartotojus siųsti prašymus stebėjimo bokštams ištrinti senas valstijas. Vartotojai gali tai padaryti per „Tor“ su tam tikru delsimu po naujos operacijos, kad galėtų numanyti privatumą.

Šis požiūris sujungtas kartu:

  1. Į privatumą orientuotas dizainas
  2. Galimybė išsaugoti tik naujausią būsenos atnaujinimą („eltoo“)
  3. Vėlavimai
  4. Vartotojo užklausos ištrinti senas būsenas

Mano nuomone, tai yra labiausiai subalansuotas požiūris į privatumą ir mastelį. Tačiau neaišku, kaip paskatinti vartotojus iniciatyviai siųsti prašymus ištrinti senas valstijas, neatsisakant jų privatumo. Mes bandysime tai išsiaiškinti kitame straipsnyje apie perspektyvius verslo modelius.

Išvada

Yra daug skirtingų privatumo ir mastelio problemų sprendimų, tačiau visi jie turi tam tikrų kompromisų. Mastelio, nepriklausančio grandinei, ateitis vis dar nėra aiški, todėl labai svarbu aptarti skirtingų dizainų privalumus ir trūkumus, pažvelgti į paskatų modelius ir kartu sumanyti naujus problemų sprendimo būdus ir sprendimus.

Kitame straipsnyje apžvelgsime atskaitomybės problemos sprendimus ir aptarsime skirtingus stebėjimo bokštų verslo modelius ir tai, kaip jie gali užsidirbti iš savo paslaugų, nes ten viskas vėl pasidarys netvarkingai.

Jei norite pamatyti daugiau nuoširdžių straipsnių apie apžvalgos bokštus, stebulius ir apskritai ne grandinės mastelio didinimo sprendimus, prašau pasidalinti šiuo straipsniu arba paaukoti čia - tai tikrai paspartins procesą.

Atsakomybės atsisakymas: nesu licencijuotas finansų patarėjas, o šis straipsnis nėra finansinis patarimas. Čia pateikta informacija skirta tik švietimo tikslams, ji atspindi mano asmeninę nuomonę ir nėra teigiama, kad tai yra faktas. Kriptovaliutos yra labai nepastovios ir gali greitai judėti bet kuria kryptimi. Aš neatsakau nei tiesiogiai, nei netiesiogiai už bet kokią žalą ar nuostolius, kuriuos sukėlė arba įtaria, kad jie sukėlė ar yra susiję su šiame straipsnyje nurodyto turinio, prekių, paslaugų ar bendrovių naudojimu ar priklausomybe nuo jų. Kreipkitės į tinkamai licencijuotą specialistą dėl investavimo patarimo.

Jei vis dar manote, kad maža „Therio“ rinkos riba negali padaryti didelės įtakos visai kriptovaliutų rinkai, tiesiog perskaitykite šį straipsnį:

  • Padėkite informuoti žmones apie LN stebėjimo bokštus ir RDN stebėjimo paslaugas iki (galite klijuoti iki 50 kartų).
  • Aš rašau tik kokybišką turinį apie kriptovaliutas ir „blockchain“. Stebėkite mane terpėje, „Twitter“ ar „mastodon“ ir jūs to nesigailėsite.
  • Atsiųskite man tiesioginę žinutę „Twitter“ ar „linkedin“ tinklalapyje, jei norite, kad padėčiau pagerinti jūsų projektą, balta knyga, svetainė; arba remti kitus mano straipsnius.
  • Naudokite saugiausią, privatiausią ir intuityviausią būdą apsikeisti eteriu (ETH) su kitais savo vietine valiuta - „LocalEthereum“.