ProHoster > Օրագիր > Վարչակազմը > IPFS առանց ցավի (բայց սա ճշգրիտ չէ)

IPFS առանց ցավի (բայց սա ճշգրիտ չէ)

IPFS առանց ցավի (բայց սա ճշգրիտ չէ)

Չնայած այն հանգամանքին, որ Հաբրեն արդեն եղել է IPFS-ի մասին մեկից ավելի հոդված.

Անմիջապես կհստակեցնեմ, որ ես այս ոլորտում մասնագետ չեմ, բայց մեկ անգամ չէ, որ հետաքրքրություն եմ ցուցաբերել այս տեխնոլոգիայի նկատմամբ, բայց դրա հետ խաղալու փորձը հաճախ որոշակի ցավ է պատճառում: Այսօր ես նորից սկսեցի փորձարկել և ստացա որոշ արդյունքներ, որոնցով կցանկանայի կիսվել: Մի խոսքով, նկարագրվելու է IPFS-ի տեղադրման գործընթացը և որոշ առանձնահատկություններ (ամեն ինչ արվել է ubuntu-ում, ես չեմ փորձել այլ հարթակներում):

Եթե ​​բաց եք թողել, թե ինչ է IPFS-ը, այստեղ մանրամասն գրված է. habr.com/en/post/314768

Տեղակայում

Փորձի մաքրության համար ես առաջարկում եմ անմիջապես տեղադրել այն ինչ-որ արտաքին սերվերի վրա, քանի որ մենք կդիտարկենք որոշ թակարդներ տեղական և հեռակառավարման ռեժիմում աշխատելու հետ կապված: Հետո ցանկության դեպքում երկար ժամանակ չի քանդվի, շատ բան չկա։

Տեղադրեք go

Պաշտոնական փաստաթղթեր
Տես ընթացիկ տարբերակը այստեղ golang.org/dl

Նշում. ավելի լավ է IPFS-ը տեղադրել այն օգտվողի անունից, ով պետք է օգտագործի այն ամենից հաճախ: Փաստն այն է, որ ստորև մենք կքննարկենք միջոցով մոնտաժման տարբերակը FUSE և կան նրբություններ:

cd ~
curl -O https://dl.google.com/go/go1.12.9.linux-amd64.tar.gz
tar xvf go1.12.9.linux-amd64.tar.gz
sudo chown -R root:root ./go
sudo mv go /usr/local
rm go1.12.9.linux-amd64.tar.gz

Ապա դուք պետք է թարմացնեք միջավայրը (ավելի մանրամասն այստեղ՝ golang.org/doc/code.html#GOPATH).

echo 'export GOPATH=$HOME/work' >> ~/.bashrc
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.bashrc
source ~/.bashrc

Ստուգելով, որ go-ը տեղադրված է

go version

Տեղադրեք IPFS

Ինձ ամենաշատը դուր եկավ տեղադրման եղանակը ipfs թարմացում.

Տեղադրեք այն հրամանով 

go get -v -u github.com/ipfs/ipfs-update

Դրանից հետո կարող եք գործարկել հետևյալ հրամանները.

ipfs-թարմացման տարբերակները - տեսնել բոլոր առկա տարբերակները ներբեռնման համար:
ipfs-update տարբերակը - ներկա պահին տեղադրված տարբերակը տեսնելու համար (մինչև մենք IPFS-ն տեղադրենք, այն չի լինի ոչ մեկը):
ipfs-update-ի տեղադրումը ամենաուշը - տեղադրել IPFS-ի վերջին տարբերակը: Վերջինի փոխարեն, համապատասխանաբար, կարող եք նշել ցանկացած ցանկալի տարբերակ առկաների ցանկից:

ipfs-ի տեղադրում

ipfs-update install latest

Ստուգեք

ipfs --version

Անմիջապես տեղադրման հետ ընդհանուր առմամբ ամեն ինչ:

Սկսեք IPFS-ը

Մեկնարկումը

Նախ պետք է կատարեք սկզբնավորումը:

ipfs init

Ի պատասխան՝ դուք կստանաք այսպիսի բան.

 ipfs init
initializing IPFS node at /home/USERNAME/.ipfs
generating 2048-bit RSA keypair...done
peer identity: QmeCWX1DD7HnXXXXXXXXXXXXXXXXXXXXXXXXxxx
to get started, enter:
	ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Դուք կարող եք գործարկել առաջարկվող հրամանը

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Արդյունք

Hello and Welcome to IPFS!

██╗██████╗ ███████╗███████╗
██║██╔══██╗██╔════╝██╔════╝
██║██████╔╝█████╗  ███████╗
██║██╔═══╝ ██╔══╝  ╚════██║
██║██║     ██║     ███████║
╚═╝╚═╝     ╚═╝     ╚══════╝

If you're seeing this, you have successfully installed
IPFS and are now interfacing with the ipfs merkledag!

 -------------------------------------------------------
| Warning:                                              |
|   This is alpha software. Use at your own discretion! |
|   Much is missing or lacking polish. There are bugs.  |
|   Not yet secure. Read the security notes for more.   |
 -------------------------------------------------------

Check out some of the other files in this directory:

  ./about
  ./help
  ./quick-start     <-- usage examples
  ./readme          <-- this file
  ./security-notes

Այստեղ, իմ կարծիքով, սկսվում է հետաքրքիրը։ Տեղադրման փուլում գտնվող տղաներն արդեն սկսում են օգտագործել սեփական տեխնոլոգիաները։ Առաջարկվող հեշը QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv չի ստեղծվել հատուկ ձեզ համար, այլ կարված է թողարկման մեջ: Այսինքն, թողարկումից առաջ նրանք պատրաստեցին ողջույնի տեքստ, այն լցրեցին IPFS-ի մեջ և ավելացրին հասցեն տեղադրողին։ Կարծում եմ, որ դա շատ թույն է: Եվ այս ֆայլը (ավելի ճիշտ՝ ամբողջ թղթապանակը) այժմ կարելի է դիտել ոչ միայն տեղական, այլև պաշտոնական դարպասում։ ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Միևնույն ժամանակ կարող եք վստահ լինել, որ թղթապանակի պարունակությունը որևէ կերպ չի փոխվել, քանի որ եթե այն փոխվեր, ապա կփոխվեր նաև հեշը։

Ի դեպ, այս դեպքում IPFS-ն որոշ նմանություններ ունի տարբերակի վերահսկման սերվերի հետ։ Եթե ​​դուք փոփոխություններ կատարեք թղթապանակի սկզբնաղբյուր ֆայլերում և նորից լցնեք թղթապանակը IPFS, ապա այն կստանա նոր հասցե: Միաժամանակ հին թղթապանակը հենց այնպես ոչ մի տեղ չի գնա և հասանելի կլինի իր նախկին հասցեով։

Ուղիղ գործարկում

ipfs daemon

Դուք պետք է ստանաք այսպիսի պատասխան.

ipfs daemon
Initializing daemon...
go-ipfs version: 0.4.22-
Repo version: 7
System version: amd64/linux
Golang version: go1.12.7
Swarm listening on /ip4/x.x.x.x/tcp/4001
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

Ինտերնետի դռների բացում

Ուշադրություն դարձրեք այս երկու տողերին.

WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080

Այժմ, եթե դուք տեղադրել եք IPFS-ը տեղական մակարդակում, ապա դուք մուտք կունենաք IPFS ինտերֆեյս տեղական հասցեներով և ամեն ինչ հասանելի կլինի ձեզ համար (օրինակ. localhost:5001/webui/): Բայց երբ տեղադրվում է արտաքին սերվերի վրա, լռելյայնորեն, դարպասները փակ են ինտերնետի համար: Դարպասներ երկու.

  1. webui ադմին (GitHub) 5001 նավահանգստում:
  2. Արտաքին API 8080 նավահանգստի վրա (միայն կարդալու):

Առայժմ երկու պորտերն էլ (5001 և 8080) կարող են բացվել փորձերի համար, բայց մարտական ​​սերվերի վրա, իհարկե, 5001 պորտը պետք է փակվի firewall-ով։ Կա նաև պորտ 4001, որն անհրաժեշտ է, որպեսզի մյուս հասակակիցները կարողանան գտնել ձեզ: Այն պետք է բաց մնա դրսի հարցումների համար:

Բացեք ~/.ipfs/config խմբագրման համար և գտեք դրա մեջ հետևյալ տողերը.

"Addresses": {
  "Swarm": [
    "/ip4/0.0.0.0/tcp/4001",
    "/ip6/::/tcp/4001"
  ],
  "Announce": [],
  "NoAnnounce": [],
  "API": "/ip4/127.0.0.1/tcp/5001",
  "Gateway": "/ip4/127.0.0.1/tcp/8080"
}

Փոխեք 127.0.0.1-ը ձեր սերվերի ip-ով և պահեք ֆայլը, այնուհետև վերագործարկեք ipfs-ը (դադարեցրեք գործող հրամանը Ctrl+C-ով և նորից գործարկեք):

Պետք է ստանալ 

...
WebUI: http://ip_вашего_сервера:5001/webui
Gateway (readonly) server listening on /ip4/ip_вашего_сервера/tcp/8080

Այժմ արտաքին միջերեսները պետք է հասանելի լինեն:

Ստուգեք

http://домен_или_ip_сервера:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Վերը նշված readme ֆայլը պետք է բացվի:

http://домен_или_ip_сервера:5001/webui/

Վեբ ինտերֆեյսը պետք է բացվի:

Եթե ​​webui-ն աշխատում է ձեզ համար, ապա IPFS-ի կարգավորումները կարող են ուղղակիորեն փոխվել դրանում, ներառյալ վիճակագրությունը դիտելը, բայց ստորև ես կքննարկեմ կազմաձևման տարբերակները անմիջապես կազմաձևման ֆայլի միջոցով, ինչը, ընդհանուր առմամբ, կարևոր չէ: Պարզապես ավելի լավ է հստակ հիշել, թե որտեղ է կոնֆիգուրը և ինչ անել դրա հետ, այլապես եթե վեբ դեմքը չաշխատի, ավելի դժվար կլինի:

Ձեր սերվերի հետ աշխատելու համար վեբ ինտերֆեյսի կարգավորում

Ահա առաջին որոգայթը, որը տևեց մոտ երեք ժամ։

Եթե ​​դուք տեղադրել եք IPFS արտաքին սերվերի վրա, բայց չեք տեղադրել կամ գործարկել IPFS-ը լոկալ, ապա երբ վեբ ինտերֆեյսում գնում եք /webui, դուք պետք է տեսնեք կապի սխալ.

IPFS առանց ցավի (բայց սա ճշգրիտ չէ)

Փաստն այն է, որ webui-ն, իմ կարծիքով, շատ երկիմաստ է աշխատում։ Նախ, այն փորձում է միանալ սերվերի API-ին, որտեղ ինտերֆեյսը բաց է (իհարկե, բրաուզերի հասցեի հիման վրա): իսկ եթե այնտեղ չի աշխատում, ապա փորձում է միանալ տեղական դարպասին։ Իսկ եթե դուք ունեք IPFS-ն աշխատում է լոկալ, ապա webui-ն ձեզ համար լավ կաշխատի, միայն դուք կաշխատեք տեղական IPFS-ով, և ոչ արտաքին, չնայած դուք բացել եք webui-ն արտաքին սերվերի վրա։ Այնուհետև վերբեռնում եք ֆայլերը, բայց ինչ-ինչ պատճառներով դրանք հենց այնպես չեք տեսնում արտաքին սերվերում…

Եվ եթե այն չի աշխատում լոկալ, ապա մենք ստանում ենք կապի սխալ: Մեր դեպքում, ամենայն հավանականությամբ, սխալը պայմանավորված է CORS-ով, որը նույնպես նշվում է webui-ի կողմից՝ առաջարկելով ավելացնել կոնֆիգուրացիա:

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://ip_вашего сервера:5001", "http://127.0.0.1:5001", "https://webui.ipfs.io"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "GET", "POST"]'

Ես հենց նոր գրանցեցի wildcard

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["*"]'

Ավելացված վերնագրերը կարելի է գտնել նույն ~/.ipfs/config-ում: Իմ դեպքում այդպես է

  "API": {
    "HTTPHeaders": {
      "Access-Control-Allow-Origin": [
        "*"
      ]
    }
  },

Մենք վերագործարկում ենք ipfs-ը և տեսնում ենք, որ webui-ն հաջողությամբ միացել է (ամեն դեպքում, դա պետք է լինի, եթե դուք բացել եք դարպասները դրսից հարցումների համար, ինչպես նկարագրված է վերևում):

Այժմ դուք կարող եք վերբեռնել թղթապանակներ և ֆայլեր անմիջապես վեբ ինտերֆեյսի միջոցով, ինչպես նաև ստեղծել ձեր սեփական թղթապանակները:

FUSE ֆայլային համակարգի տեղադրում

Ահա մի բավականին հետաքրքիր առանձնահատկություն.

Ֆայլեր (ինչպես նաև թղթապանակներ), մենք կարող ենք ավելացնել ոչ միայն վեբ ինտերֆեյսի միջոցով, այլ նաև ուղղակիորեն տերմինալում, օրինակ.

ipfs add test -r
added QmfYuz2gegRZNkDUDVLNa5DXzKmxxxxxxxxxx test/test.txt
added QmbnzgRVAP4fL814h5mQttyqk1aURxxxxxxxxxxxx test

Վերջին հեշը արմատային թղթապանակի հեշն է:

Օգտագործելով այս հեշը, մենք կարող ենք թղթապանակ բացել ցանկացած ipfs հանգույցի վրա (որը կարող է գտնել մեր հանգույցը և ստանալ բովանդակությունը), մենք կարող ենք վեբ ինտերֆեյսում 5001 կամ 8080 նավահանգստի վրա, կամ կարող ենք տեղական ipfs-ի միջոցով:

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Բայց դուք դեռ կարող եք բացել այն սովորական թղթապանակի նման:

Եկեք արմատից ստեղծենք երկու թղթապանակ և նրանց իրավունքներ շնորհենք մեր օգտատիրոջը:

sudo mkdir /ipfs /ipns
sudo chown USERNAME /ipfs /ipns

և վերագործարկեք ipfs-ը --mount դրոշով

ipfs daemon --mount

Դուք կարող եք ստեղծել թղթապանակներ այլ վայրերում և նշել ipfs daemon պարամետրերի միջոցով դեպի ուղին -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path:

Այժմ այս թղթապանակից կարդալը որոշ չափով անսովոր է:

ls -la /ipfs
ls: reading directory '/ipfs': Operation not permitted
total 0

Այսինքն, այս թղթապանակի արմատին ուղղակի մուտք չկա: Բայց դուք կարող եք ստանալ բովանդակությունը, իմանալով հեշը:

ls -la /ipfs/QmbnzgRVAP4fL814h5mQttyqxxxxxxxxxxxxxxxxx
total 0
-r--r--r-- 1 root root 10 Aug 31 07:03 test.txt


cat /ipfs/QmbnzgRVAP4fL814h5mQttyqxxxxxxxxxxxxxxxxx/test.txt 
test
test

Միևնույն ժամանակ, նույնիսկ ավտոմատ լրացումն աշխատում է թղթապանակի ներսում, երբ ուղին նշված է:

Ինչպես վերևում ասացի, նման մոնտաժման հետ կապված կան նրբություններ. լռելյայնորեն, տեղադրված FUSE թղթապանակները հասանելի են միայն ընթացիկ օգտագործողին (նույնիսկ root-ը չի կարողանա կարդալ այդպիսի թղթապանակից, էլ չեմ խոսում համակարգի այլ օգտվողների մասին): Եթե ​​ցանկանում եք այս թղթապանակները հասանելի դարձնել այլ օգտատերերի համար, ապա կոնֆիգուրայում դուք պետք է փոխեք «FuseAllowOther»՝ false «FuseAllowOther»՝ true: Բայց սա դեռ ամենը չէ: Եթե ​​դուք գործարկում եք IPFS-ը որպես արմատ, ապա ամեն ինչ կարգին է: Իսկ եթե սովորական օգտատիրոջ անունից (նույնիսկ sudo), ապա դուք սխալ կստանաք

mount helper error: fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf

Այս դեպքում, դուք պետք է խմբագրեք /etc/fuse.conf՝ չմեկնաբանելով #user_allow_other տողը:

Դրանից հետո վերագործարկեք ipfs-ը:

FUSE-ի հետ կապված հայտնի խնդիրներ

Խնդիրը մեկ անգամ չէ, որ նկատվել է, որ ipfs-ը մոնտաժով վերագործարկելուց հետո (և միգուցե այլ դեպքերում) /ipfs և /ipns մոնտաժային կետերն անհասանելի են դառնում։ Դրանց հասանելիություն չկա, իսկ ls -la /ipfs-ը ցույց է տալիս ???? իրավունքների ցանկում։

Գտա այս լուծումը.

fusermount -z -u /ipfs
fusermount -z -u /ipns

Այնուհետև վերագործարկեք ipfs-ը:

Ծառայության ավելացում

Իհարկե, տերմինալում աշխատելը հարմար է միայն նախնական թեստերի համար: Մարտական ​​ռեժիմում դեյմոնը պետք է ավտոմատ կերպով գործարկվի համակարգի գործարկման ժամանակ:

Sudo-ի անունից ստեղծեք /etc/systemd/system/ipfs.service ֆայլը և գրեք դրան.

[Unit]
Description=IPFS Daemon
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
ExecStart=/home/USERNAME/work/bin/ipfs daemon --mount
User=USERNAME
Restart=always

[Install]
WantedBy=multi-user.target

USERNAME-ը, իհարկե, պետք է փոխարինվի ձեր օգտագործողով (և միգուցե ipfs ծրագրի ամբողջական ուղին ձեզ համար տարբեր լինի (դուք պետք է նշեք ամբողջական ուղին)):

Մենք ակտիվացնում ենք ծառայությունը։

sudo systemctl enable ipfs.service

Մենք սկսում ենք ծառայությունը.

sudo service ipfs start

Ծառայության կարգավիճակի ստուգում:

sudo service ipfs status

Փորձի մաքրության համար ապագայում հնարավոր կլինի վերագործարկել սերվերը՝ ստուգելու, որ ipfs-ը հաջողությամբ ինքնաբերաբար սկսվում է:

Մեզ հայտնի խնջույքների ավելացում

Դիտարկենք մի իրավիճակ, երբ մենք ունենք IPFS հանգույցներ տեղադրված ինչպես արտաքին սերվերի վրա, այնպես էլ տեղական: Արտաքին սերվերի վրա մենք ավելացնում ենք որոշ ֆայլ և փորձում ենք այն ստանալ IPFS-ի միջոցով տեղական՝ CID-ի միջոցով: Ի՞նչ է լինելու։ Իհարկե, տեղական սերվերը, ամենայն հավանականությամբ, ոչինչ չգիտի մեր արտաքին սերվերի մասին և պարզապես կփորձի գտնել ֆայլը CID-ով՝ «հարցնելով» իրեն հասանելի բոլոր IPFS հասակակիցներին (որի հետ նա արդեն հասցրել է «ծանոթանալ»): Նրանք իրենց հերթին կհարցնեն ուրիշներին. Եվ այսպես շարունակ, մինչև ֆայլը գտնվի: Փաստորեն, նույնը տեղի է ունենում, երբ մենք փորձում ենք ֆայլը ստանալ պաշտոնական դարպասի միջոցով ipfs.io. Եթե ​​ձեր բախտը բերի, ֆայլը կգտնվի մի քանի վայրկյանից: Իսկ եթե ոչ, ապա այն չի գտնվի նույնիսկ մի քանի րոպեում, ինչը մեծապես ազդում է աշխատանքի հարմարավետության վրա։ Բայց մենք գիտենք, թե որտեղ է առաջին անգամ հայտնվել այս ֆայլը: Այսպիսով, ինչու մենք անմիջապես չենք ասում մեր տեղական սերվերին «Նախ որոնել այնտեղ»: Ըստ երևույթին, դա հնարավոր է անել:

1. Մենք գնում ենք հեռավոր սերվեր և փնտրում ենք ~/.ipfs/config կոնֆիգուրացիա 

"Identity": {
    "PeerID": "QmeCWX1DD7HnPSuMHZSh6tFuxxxxxxxxxxxxxxxx",

2. Գործարկեք sudo ծառայության ipfs կարգավիճակը և դրանում փնտրեք Swarm գրառումները, օրինակ.

Swarm announcing /ip4/ip_вашего_сервера/tcp/4001

3. Սրանից ավելացնում ենք «/ip4/ip_your_server/tcp/4001/ipfs/$PeerID» ձևի ընդհանուր հասցեն։

4. Հուսալիության համար մենք կփորձենք ավելացնել այս հասցեն հասակակիցներին մեր տեղական webui-ի միջոցով:

IPFS առանց ցավի (բայց սա ճշգրիտ չէ)

5. Եթե ամեն ինչ կարգին է, բացեք լոկալ կոնֆիգուրգը ~ / .ipfs / config, դրա մեջ գտեք «Bootstrap»՝ [...
և զանգվածին նախ ավելացրեք ստացված հասցեն:

Վերագործարկեք IPFS-ը:

Հիմա եկեք ֆայլը ավելացնենք արտաքին սերվերին և փորձենք պահանջել այն տեղականի վրա: Պետք է արագ թռչել:

Բայց այս ֆունկցիոնալությունը դեռ կայուն չէ: Որքան հասկանում եմ, եթե նույնիսկ Bootstrap-ում նշենք հասակակիցի հասցեն, ipfs-ը շահագործման ընթացքում փոխում է գործընկերների հետ ակտիվ կապերի ցանկը։ Համենայնդեպս, այս և ցանկությունների քննարկումը շարունակվում է մշտական ​​խնջույքների հստակեցման հնարավորության վերաբերյալ այստեղ և կարծես թե ենթադրյալ ավելացնել որոշ գործառույթներ [էլեկտրոնային փոստով պաշտպանված]+

Ընթացիկ գործընկերների ցանկը կարելի է դիտել ինչպես webui-ում, այնպես էլ տերմինալում: 

ipfs swarm peers

Եվ արի ու տես, որ դուք կարող եք ձեռքով ավելացնել ձեր խնջույքը: 

ipfs swarm connect "/ip4/ip_вашего_сервера/tcp/4001/ipfs/$PeerID"

Քանի դեռ այս ֆունկցիոնալությունը չի բարելավվել, դուք կարող եք գրել գործիք՝ ստուգելու համար կապը ցանկալի գործընկերոջ հետ, իսկ եթե ոչ՝ կապ ավելացնելու համար:

Փաստարկ

Նրանց թվում, ովքեր արդեն ծանոթ են IPFS-ին, կան IPFS-ին և՛ կողմ, և՛ դեմ փաստարկներ: Հիմնականում երեկ քննարկում և ինձ հուշեց նորից փորփրել IPFS-ը: Իսկ ինչ վերաբերում է վերը նշված քննարկմանը. ես չեմ կարող ասել, որ կտրականապես դեմ եմ խոսողների որևէ փաստարկի (համաձայն չեմ միայն այն փաստի հետ, որ մեկուկես ծրագրավորողներ օգտագործում են IPFS): Ընդհանրապես, երկուսն էլ յուրովի ճիշտ են (հատկապես մեկնաբանություն չեկերի մասին ստիպում է մտածել): Բայց եթե մենք հրաժարվենք բարոյական և իրավական գնահատականից, ո՞վ կտա այս տեխնոլոգիայի տեխնիկական գնահատականը: Անձամբ ես ինչ-որ ներքին զգացողություն ունեմ, որ «սա պետք է անել միանշանակ, դա որոշակի հեռանկարներ ունի»։ Բայց ինչու կոնկրետ, հստակ ձեւակերպում չկա։ Օրինակ, եթե նայեք առկա կենտրոնացված գործիքներին, ապա շատ առումներով դրանք շատ առաջ են (կայունություն, արագություն, կառավարելիություն և այլն): Այնուամենայնիվ, ես մի միտք ունեմ, որը կարծես թե իմաստալից է, և որը դժվար թե հնարավոր լինի իրականացնել առանց նման ապակենտրոնացված համակարգերի։ Իհարկե, ես չափից դուրս ճոճում եմ, բայց դա կձևակերպեի այսպես՝ պետք է փոխել համացանցում տեղեկատվության տարածման սկզբունքը։

Թույլ տուր բացատրեմ. Եթե ​​մտածեք դրա մասին, հիմա մենք ունենք տեղեկատվություն, որը տարածվում է «Հուսով եմ, որ նա, ում ես տվել եմ, կպաշտպանի այն, և այն չի կորչի կամ ստանա նրանք, ում դա նախատեսված չէր» սկզբունքով: Որպես օրինակ, հեշտ է դիտարկել տարբեր փոստային ծառայություններ, ամպային պահեստներ և այլն: Իսկ ինչի՞ հետ ենք վերջանում: Հաբրե հանգույցում Տեղեկատվական անվտանգություն գտնվում է առաջին գծում և գրեթե ամեն օր նորություններ ենք ստանում հերթական համաշխարհային արտահոսքի մասին։ Սկզբունքորեն, բոլոր ամենահետաքրքիր բաները թվարկված են <հեգնանք> հրաշալի հոդված Ամառը գրեթե ավարտված է։ Անհայտ տվյալներ գրեթե չեն մնացել. Այսինքն՝ հիմնական ինտերնետային հսկաները դառնում են ավելի մեծ, նրանք ավելի ու ավելի շատ տեղեկություններ են կուտակում, իսկ նման արտահոսքերը յուրատեսակ տեղեկատվական ատոմային պայթյուններ են։ Նման բան նախկինում երբեք չի եղել, և ահա նորից: Միևնույն ժամանակ, թեև շատերը հասկանում են, որ կան ռիսկեր, նրանք կշարունակեն վստահել իրենց տվյալները երրորդ կողմի ընկերություններին: Նախ՝ այլընտրանք չկա, երկրորդ՝ խոստանում են, որ բոլոր փոսերը կարկատել են, և դա երբեք չի կրկնվի։

Ինչ տարբերակ եմ տեսնում: Ինձ թվում է, որ սկզբում տվյալները պետք է բաց տարածվեն։ Բայց բաց լինելն այս դեպքում չի նշանակում, որ ամեն ինչ պետք է հեշտ ընթեռնելի լինի։ Ես խոսում եմ պահեստավորման և բաշխման բաց լինելու մասին, բայց ոչ ընթերցանության ամբողջական բացության մասին: Ես ենթադրում եմ, որ տեղեկատվությունը պետք է տարածվի հանրային բանալիներով: Ի վերջո, հանրային / մասնավոր բանալիների սկզբունքն արդեն հին է, գրեթե ինտերնետի նման: Եթե ​​տեղեկատվությունը գաղտնի չէ և նախատեսված է լայն շրջանակի համար, ապա այն դրվում է անմիջապես հանրային բանալիով (բայց դեռ կոդավորված ձևով, պարզապես ցանկացած ոք կարող է այն վերծանել հասանելի բանալիով): Եվ եթե ոչ, ապա այն դրվում է առանց հանրային բանալիի, և բանալին ինքնին փոխանցվում է այն, ինչին պետք է հասանելի լինի այս տեղեկատվությունը: Միևնույն ժամանակ, նա, ով պետք է այն կարդա, պետք է ունենա միայն բանալի, և որտեղից ստանալ այդ տեղեկատվությունը, նա իրականում չպետք է սավառնի. նա պարզապես այն հանում է ցանցից (սա բովանդակության բաշխման նոր սկզբունքն է, ոչ թե ըստ բովանդակության. հասցե):

Այսպիսով, զանգվածային հարձակման համար հարձակվողները պետք է ստանան հսկայական թվով անձնական բանալիներ, և դա դժվար թե կատարվի մեկ վայրում: Այս առաջադրանքը, ինչպես տեսնում եմ, ավելի դժվար է, քան կոնկրետ ծառայություն կոտրելը:

Եվ այստեղ փակվում է մեկ այլ խնդիր՝ հեղինակության հաստատումը։ Այժմ համացանցում կարող եք գտնել բազմաթիվ մեջբերումներ, որոնք գրված են մեր ընկերների կողմից: Բայց որտե՞ղ է երաշխիքը, որ հենց իրենք են գրել դրանք։ Հիմա, եթե յուրաքանչյուր նման գրառում ուղեկցվեր թվային ստորագրությամբ, շատ ավելի հեշտ կլիներ։ Եվ կապ չունի, թե որտեղ է այս տեղեկությունը, գլխավորը ստորագրությունն է, որը, իհարկե, դժվար է կեղծել։

Եվ ահա թե ինչ հետաքրքիր է այստեղ. IPFS-ն արդեն կրում է կոդավորման գործիքներ (ի վերջո, այն կառուցված է բլոկչեյն տեխնոլոգիայի վրա): Անձնական բանալին անմիջապես նշվում է կազմաձևում:

  "Identity": {
    "PeerID": "QmeCWX1DD7HnPSuMHZSh6tFuMxxxxxxxxxxxxxx",
    "PrivKey": "CAASqAkwggSkAgEAAoIBAQClZedVmj8JkPvT92sGrNIQmofVF3ne8xSWZIGqkm+t9IHNN+/NDI51jA0MRzpBviM3o/c/Nuz30wo95vWToNyWzJlyAISXnUHxnVhvpeJAbaeggQRcFxO9ujO9DH61aqgN1m+JoEplHjtc4KS5
pUEDqamve+xAJO8BWt/LgeRKA70JN4hlsRSghRqNFFwjeuBkT1kB6tZsG3YmvAXJ0o2uye+y+7LMS7jKpwJNJBiFAa/Kuyu3W6PrdOe7SqrXfjOLHQ0uX1oYfcqFIKQsBNj/Fb+GJMiciJUZaAjgHoaZrrf2b/Eii3z0i+QIVG7OypXT3Z9JUS60
KKLfjtJ0nVLjAgMBAAECggEAZqSR5sbdffNSxN2TtsXDa3hq+WwjPp/908M10QQleH/3mcKv98FmGz65zjfZyHjV5C7GPp24e6elgHr3RhGbM55vT5dQscJu7SGng0of2bnzQCEw8nGD18dZWmYJsE4rUsMT3wXxhUU4s8/Zijgq27oLyxKNr9T7
2gxqPCI06VTfMiCL1wBBUP1wHdFmD/YLJwOjV/sVzbsl9HxqzgzlDtfMn/bJodcURFI1sf1e6WO+MyTc3.................

Ես անվտանգության մասնագետ չեմ և չեմ կարող հստակ իմանալ, թե ինչպես օգտագործել այն ճիշտ, բայց ինձ թվում է, որ այս բանալիներն օգտագործվում են IPFS հանգույցների միջև փոխանակման մակարդակում: Ինչպես նաեւ js-ipfs և օրինակ նախագծեր, ինչպիսիք են ուղեծիր-dbորի վրա այն աշխատում է orbit.chat. Այսինքն՝ տեսականորեն յուրաքանչյուր սարք (բջջային և ոչ միայն) հեշտությամբ կարող է համալրվել սեփական կոդավորման-գաղտնազերծման մեքենաներով։ Այս դեպքում մնում է միայն, որ բոլորը հոգ տանեն իրենց անձնական բանալիների պահպանման մասին, և յուրաքանչյուրը պատասխանատվություն է կրելու իր անվտանգության համար, այլ ոչ թե լինել մեկ այլ մարդկային գործոնի պատանդ ինչ-որ գերժողովրդական ինտերնետ հսկայի վրա։

Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ Մուտք գործել, խնդրում եմ:

Նախկինում լսե՞լ եք IPFS-ի մասին:

  • Ես երբեք չեմ լսել IPFS-ի մասին, բայց հետաքրքիր է թվում

  • Չեմ լսել և չեմ ուզում լսել

  • Լսել է, բայց չի հետաքրքրում

  • Լսեցի, բայց չհասկացա, բայց հիմա հետաքրքիր է թվում

  • Ես երկար ժամանակ ակտիվորեն օգտագործում եմ IPFS-ը։

Քվեարկել է 69 օգտատեր։ 13 օգտատեր ձեռնպահ է մնացել։

Source: www.habr.com

Добавить комментарий