Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,150 @@
---
title: Utaratibu rahisi wa kupanga
description: Ufafanuzi wa muundo wa SSZ wa Ethereum.
lang: sw
sidebarDepth: 2
---

**Serializesheni Rahisi (SSZ)** ni mbinu ya userializesheni inayotumika kwenye Mnyororo Kioleza. Inachukua nafasi ya usanifu wa RLP unaotumiwa kwenye safu ya utekelezaji kila mahali kwenye safu ya makubaliano isipokuwa itifaki ya ugunduzi wa programu zingine. Ili kupata maelezo zaidi kuhusu serializesheni ya RLP, tazama [Kiambishi awali cha urefu kinachojirudia (RLP)](/developers/docs/data-structures-and-encoding/rlp/). SSZ imeundwa kubainisha na pia Merkleize kwa ufanisi. SSZ inaweza kuzingatiwa kuwa na vipengee viwili: mpango wa kuratibu na mpango wa Merkleization ambao umeundwa kufanya kazi kwa ufanisi na muundo wa data uliosanifiwa.

## SSZ inafanya kazi vipi? {#how-does-ssz-work}

### Serializesheni {#serialization}

SSZ ni mpango wa kuratibu ambao haujielezi - badala yake unategemea mpango ambao lazima ujulikane mapema. Kusudi la usanifu wa SSZ ni kuwakilisha vitu vya ugumu wa kiholela kama kamba za baiti. Huu ni mchakato rahisi sana kwa "aina za msingi". Kipengele kinabadilishwa tu kuwa baiti za hexadecimal. Aina za msingi ni pamoja na:

- nambari kamili ambazo hazijasainiwa
- Thamani za Mantiki

Kwa aina tata za "mchanganyiko", usakinishaji ni mgumu zaidi kwa sababu aina ya mchanganyiko ina vipengele vingi ambavyo vinaweza kuwa na aina tofauti au ukubwa tofauti, au zote mbili. Ikiwa vitu hivi vyote vina urefu usiobadilika (yaani, ukubwa wa vipengele daima ni wa kudumu bila kujali thamani zao halisi), userializesheni ni ubadilishaji rahisi wa kila kipengele katika aina ya mchanganyiko, unaopangwa katika mifuatano ya baiti ya mwisho-mdogo. Mlolongo huu wa baiti huunganishwa pamoja. Kitu kilichofanyiwa usanifu huwa na mwakilishi wa orodha ya baiti wa vipengele vyenye urefu wa kudumu katika mpangilio uleule kama vinavyoonekana kwenye kitu kilichorudishwa.

Kwa aina zilizo na urefu tofauti, data halisi hubadilishwa na thamani ya "kukabiliana" katika nafasi ya kipengele hicho katika kitu kilichosanifiwa. Data halisi huongezwa kwenye lundo mwishoni mwa kitu kilichopangwa mfululizo. Thamani ya kukabiliana ni tofauti tofauti ya kuanza kwa data halisi kwenye lundo, ikifanya kazi kama kiashirio kwa baiti husika.

Mfano hapa chini unaonyesha jinsi urekebishaji unavyofanya kazi kwa kontena iliyo na vitu vilivyowekwa na vya urefu tofauti:

```Rust

struct Dummy {

number1: u64,
number2: u64,
vector: Vec<u8>,
number3: u64
}

dummy = Dummy{

number1: 37,
number2: 55,
vector: vec![1,2,3,4],
number3: 22,
}

serialized = ssz.serialize(dummy)

```

`serialized` ingekuwa na muundo ufuatao (imejazwa kwa biti 4 tu hapa, imejazwa kwa biti 32 katika uhalisia, na kuweka uwakilishi wa `int` kwa uwazi):

```
[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4]
------------ ----------- ----------- ----------- ----------
| | | | |
namba1 namba2 punguzo kwa namba 3 thamani ya
vekta vekta

```

kugawanywa juu ya mistari kwa uwazi:

```
[
37, 0, 0, 0, # usimbaji wa mwisho-mdogo wa `namba1`.
55, 0, 0, 0, # usimbaji wa mwisho-mdogo wa `namba2`.
16, 0, 0, 0, # "Punguzo" linaloonyesha mahali ambapo thamani ya `vekta` huanza (mwisho-mdogo 16).
22, 0, 0, 0, # usimbaji wa mwisho-mdogo wa `namba3`.
1, 2, 3, 4, # Thamani halisi katika `vekta`.
]
```

Bado hii ni kurahisisha - nambari kamili na sifuri kwenye michoro hapo juu zingehifadhiwa kwa njia, kama hii:

```
[
10100101000000000000000000000000 # usimbaji wa mwisho-mdogo wa `namba1`
10110111000000000000000000000000 # usimbaji wa mwisho-mdogo wa `namba2`.
10010000000000000000000000000000 # "Punguzo" linaloonyesha mahali ambapo thamani ya `vekta` huanza (mwisho-mdogo 16).
10010110000000000000000000000000 # usimbaji wa mwisho-mdogo wa `namba3`.
10000001100000101000001110000100 # Thamani halisi ya sehemu ya `baiti`.
]
```

Kwa hivyo maadili halisi ya aina za urefu tofauti huhifadhiwa kwenye lundo mwishoni mwa kitu kilichopangwa kwa mpangilio na urekebishaji wao ukihifadhiwa katika nafasi zao sahihi katika orodha ya sehemu zilizoagizwa.

Pia kuna baadhi ya kesi maalum zinazohitaji matibabu maalum, kama vile aina ya `BitList` inayohitaji kikomo cha urefu kuongezwa wakati wa userializesheni na kuondolewa wakati wa uondoaji-serializesheni. Maelezo kamili yanapatikana katika [maelezo ya SSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md).

### Uondoaji-serializesheni {#deserialization}

Uondoaji-serializesheni wa kitu hiki unahitaji <b>skema</b>. Ratiba inafafanua mpangilio sahihi wa data iliyosawazishwa ili kila kipengele mahususi kiweze kuondolewa kutoka kwenye sehemu ya baiti hadi kwenye kitu fulani cha maana na vipengele vilivyo na aina, thamani, ukubwa na nafasi sahihi. Ni muundo wa data unaomwambia msanifukwa ni maadili gani ni maadili halisi na ni yapi ambayo yamepunguzwa. Majina yote ya sehemu hupotea wakati kitu kinapofanyiwa usanifu, lakini hurudishwa tena wakati wa Urejeshaji wa data katika muundo wake wa asili kulingana na muundo wa data.

Tazama [ssz.dev](https://www.ssz.dev/overview) kwa maelezo shirikishi kuhusu hili.

## Umerkleizesheni {#merkleization}

Kipengee hiki cha serialized cha SSZ kinaweza kisha kuwa merkleized - ambacho kinabadilishwa kuwa uwakilishi wa mti wa Merkle wa data sawa. Kwanza, idadi ya Vipande 32-baiti katika Kipengele kilichoorodheshwa kimeamuliwa. Hizi ni "majani" ya mti. Idadi ya jumla ya majani lazima iwe na nguvu ya 2 ili kuharakisha pamoja majani hatimaye kutoa mzizi mmoja wa mti wa hashi. Ikiwa hii sio kawaida, majani ya ziada yaliyo na baiti 32 za zero huongezwa. Kielelezo:

```
mzizi wa mti wa hashi
/ \
/ \
/ \
/ \
hashi ya majani hashi ya majani
1 na 2 3 na 4
/ \ / \
/ \ / \
/ \ / \
jani1 jani2 jani3 jani4
```

Pia kuna matukio ambapo majani ya mti hayana kawaida sawasawa kusambaza kwa njia ya kufanya katika mfano hapo juu. Kwa mfano, jani la 4 linaweza kuwa chombo chenye vipengele vingi vinavyohitaji "kina" cha ziada ili kuongezwa kwenye mti wa Merkle, na kuunda mti usio na usawa.

Badala ya kurejelea vipengele hivi vya mti kama jani X, nodi X n. k, tunaweza kuvipa viashiria vya jumla, tukianza na mzizi = 1 na kuhesabu kutoka kushoto kwenda kulia kwa kila ngazi. Hiki ni kiashiria juimuishi kiliyoelezwa hapo juu. Kila kipengele katika orodha iliyofanyiwa userializesheni kina faharasa ya jumla sawa na `2**depth + idx` ambapo idx ni nafasi yake yenye faharasa-sifuri katika kitu kilichofanyiwa userializesheni na kina ni idadi ya viwango katika mti wa Merkle, ambayo inaweza kubainishwa kama logariti ya msingi-mbili ya idadi ya vipengele (majani).

## Faharasa za jumla {#generalized-indices}

Faharasa ya jumla ni nambari kamili inayowakilisha nodi katika mti wa Merkle wa binary ambapo kila nodi ina faharasa ya jumla `2 ** depth + index in row`.

```
1 --kina = 0 2**0 + 0 = 1
2 3 --kina = 1 2**1 + 0 = 2, 2**1+1 = 3
4 5 6 7 --kina = 2 2**2 + 0 = 4, 2**2 + 1 = 5...

```

"Uwakilishi huu unatoa kiashiria cha nodi kwa kila kipande cha data katika mti wa Merkle."

## Uthibitisho-anuwai {#multiproofs}

"Kutoa orodha ya viashiria vilivyopanuliwa vinavyo wakilisha kipengele fulani kunaturuhusu kukithibitisha dhidi ya mizizi ya mti wa hash." Mzizi huu ni toleo letu la ukweli linalokubalika. Data yoyote tunayopewa inaweza kuthibitishwa dhidi ya ukweli huo kwa kuiingiza mahali pazuri katika mti wa Merkle na kuzingatia kwamba mzizi unabaki bila kubadilika. Kuna kazi katika maelezo [hapa](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) zinazoonyesha jinsi ya kukokotoa seti ndogo iwezekanavyo ya nodi zinazohitajika ili kuthibitisha maudhui ya seti maalum ya faharasa za jumla.

Kwa mfano, ili kuthibitisha data katika fahirisi ya 9 kwenye mti ulio hapa chini, tunahitaji heshi ya data katika kiashiria 8, 9, 5, 3, 1.
Heshi ya (8,9) inapaswa kuwa sawa na (4), ambayo heshi na 5 kutoa 2, ambayo heshi yenye 3 ili kutoa mzizi wa mti 1. Ikiwa data isiyo sahihi ilitolewa kwa 9, mzizi ungebadilika - tungegundua hii na kushindwa kuthibitisha tawi.

```
* = data inayohitajika ili kutoa uthibitisho

1*
2 3*
4 5* 6 7
8* 9* 10 11 12 13 14 15

```

## Masomo zaidi {#further-reading}

- [Kuboresha Ethereum: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz)
- [Kuboresha Ethereum: Umerkleizesheni](https://eth2book.info/altair/part2/building_blocks/merkleization)
- [Utekelezaji wa SSZ](https://github.com/ethereum/consensus-specs/issues/2138)
- [Kikokotoo cha SSZ](https://simpleserialize.com/)
- [SSZ.dev](https://www.ssz.dev/)
Original file line number Diff line number Diff line change
@@ -0,0 +1,195 @@
---
title: Tovuti ya tatu ufafanuzi wa uhifadhi
description: Ufafanuzi rasmi wa ghala ya siri ya web3
lang: sw
sidebarDepth: 2
---

Ili kufanya programu yako ifanye kazi kwenye Ethereum, unaweza kutumia kitu cha web3 kinachotolewa na maktaba ya web3.js. Kimsingi huwasiliana na nodi ya ndani kupitia wito za RPC. [web3](https://github.com/ethereum/web3.js/) hufanya kazi na nodi yoyote ya Ethereum ambayo inaonyesha safu ya RPC.

`web3` ina kitu cha `eth` - web3.eth.

```js
var fs = require("fs")
var recognizer = require("ethereum-keyfile-recognizer")

fs.readFile("keyfile.json", (err, data) => {
var json = JSON.parse(data)
var result = recognizer(json)
})

/** matokeo
* [ 'web3', 3 ] faili la ufunguo la web3 (v3)
* [ 'ethersale', undefined ] Faili la ufunguo la Ethersale
* null faili la ufunguo batili
*/
```

Hati hii inaandika **toleo la 3** la Ufafanuzi wa Ghala la Siri la Web3.

## Ufafanuzi {#definition}

Usimbaji na uondoaji usimbaji halisi wa faili haujabadilika kwa kiasi kikubwa kutoka toleo la 1, isipokuwa kwamba algoriti ya kripto haijawekwa tena kwa AES-128-CBC (AES-128-CTR sasa ndiyo hitaji la chini kabisa). Maana/algoriti nyingi ni sawa na toleo la 1, isipokuwa `mac`, ambayo hutolewa kama SHA3 (keccak-256) ya miunganisho ya baiti 16 za pili kutoka kushoto za ufunguo uliotolewa pamoja na `ciphertext` kamili.

Faili za ufunguo wa siri huhifadhiwa moja kwa moja katika `~/.web3/keystore` (kwa mifumo inayofanana na Unix) na `~/AppData/Web3/keystore` (kwa Windows). Zinaweza kupewa jina lolote, lakini utaratibu mzuri ni `<uuid>.json`, ambapo `<uuid>` ni UUID ya biti 128 iliyopewa ufunguo wa siri (wakala wa kuhifadhi faragha kwa anwani ya ufunguo wa siri).

Faili zote kama hizo zina nenosiri linalohusishwa. Ili kupata ufunguo wa siri wa faili fulani ya `.json`, kwanza pata ufunguo wa usimbaji fiche wa faili; hii inafanywa kwa kuchukua nenosiri la faili na kulipitisha kupitia kitendakazi cha kupata ufunguo kama ilivyoelezwa na ufunguo wa `kdf`. Vigezo vya kudumu na vinavyobadilika vinavyotegemea KDF kwa kitendakazi cha KDF vimeelezwa katika ufunguo wa `kdfparams`.

PBKDF2 lazima iungwe mkono na utekelezaji wote unaokidhi viwango vya chini kabisa, unaoonyeshwa kupitia:

- `kdf`: `pbkdf2`

Kwa PBKDF2, kdfparams zinajumuisha:

- `prf`: Lazima iwe `hmac-sha256` (inaweza kupanuliwa siku zijazo);
- `c`: idadi ya marudio;
- `salt`: chumvi iliyopitishwa kwa PBKDF;
- `dklen`: urefu wa ufunguo uliotolewa. Lazima iwe >= 32.

Mara ufunguo wa faili utakapopatikana, unapaswa kuthibitishwa kupitia upatikanaji wa MAC. MAC inapaswa kukokotolewa kama hashi ya SHA3 (keccak-256) ya safu ya baiti iliyoundwa kama miunganisho ya baiti 16 za pili kutoka kushoto za ufunguo uliotolewa na yaliyomo kwenye ufunguo wa `ciphertext`, yaani:

```js
KECCAK(DK[16..31] ++ <ciphertext>)
```

(ambapo `++` ni kiendeshaji cha kuunganisha)

Thamani hii inapaswa kulinganishwa na yaliyomo kwenye ufunguo wa `mac`; ikiwa ni tofauti, nenosiri mbadala linapaswa kuombwa (au operesheni isitishwe).

Baada ya ufunguo wa faili kuthibitishwa, maandishi ya kificho (ufunguo wa `ciphertext` katika faili) yanaweza kuondolewa usimbaji kwa kutumia algoriti ya usimbaji fiche linganifu iliyoainishwa na ufunguo wa `cipher` na kuwekewa vigezo kupitia ufunguo wa `cipherparams`. Ikiwa saizi ya ufunguo uliotolewa na saizi ya ufunguo wa algoriti hazifanani, baiti za kulia kabisa za ufunguo uliotolewa, zilizojazwa na sifuri, zinapaswa kutumika kama ufunguo wa algoriti.

Utekelezaji wote unaokidhi viwango vya chini kabisa lazima uunge mkono algoriti ya AES-128-CTR, inayoonyeshwa kupitia:

- `cipher: aes-128-ctr`

Kificho hiki huchukua vigezo vifuatavyo, vilivyotolewa kama funguo za ufunguo wa cipherparams:

- `iv`: vekta ya kuanzisha ya biti 128 kwa kificho.

Ufunguo wa kificho ni baiti 16 za kushoto kabisa za ufunguo uliotolewa, yaani, `DK[0..15]`

Uundaji/usimbaji fiche wa ufunguo wa siri unapaswa kuwa kinyume cha maagizo haya kimsingi. Hakikisha `uuid`, `salt` na `iv` ni za kubahatisha.

Mbali na sehemu ya `version`, ambayo inapaswa kufanya kazi kama kitambulisho "kigumu" cha toleo, utekelezaji unaweza pia kutumia `minorversion` kufuatilia mabadiliko madogo, yasiyovunja, kwa umbizo.

## Vekta za Majaribio {#test-vectors}

Maelezo:

- `Anwani`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b`
- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67`
- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6`
- `Nenosiri`: `testpassword`
- `Siri`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d`

### PBKDF2-SHA-256 {#PBKDF2-SHA-256}

Vekta ya majaribio inayotumia `AES-128-CTR` na `PBKDF2-SHA-256`:

Yaliyomo kwenye faili ya `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`:

```json
{
"crypto": {
"cipher": "aes-128-ctr",
"cipherparams": {
"iv": "6087dab2f9fdbbfaddc31a909735c1e6"
},
"ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46",
"kdf": "pbkdf2",
"kdfparams": {
"c": 262144,
"dklen": 32,
"prf": "hmac-sha256",
"salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd"
},
"mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2"
},
"id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
"version": 3
}
```

**Hatua za kati**:

`Ufunguo uliotolewa`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551`
`Mwili wa MAC`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46`
`MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2`
`Ufunguo wa kificho`: `f06d69cdc7da0faffb1008270bca38f5`

### Scrypt {#scrypt}

Vekta ya majaribio inayotumia AES-128-CTR na Scrypt:

```json
{
"crypto": {
"cipher": "aes-128-ctr",
"cipherparams": {
"iv": "740770fce12ce862af21264dab25f1da"
},
"ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2",
"kdf": "scrypt",
"kdfparams": {
"dklen": 32,
"n": 262144,
"p": 1,
"r": 8,
"salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034"
},
"mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c"
},
"id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
"version": 3
}
```

**Hatua za kati**:

`Ufunguo uliotolewa`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d`
`Mwili wa MAC`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2`
`MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c`
`Ufunguo wa kificho`: `7446f59ecc301d2d79bc3302650d8a5c`

## Mabadiliko kutoka Toleo la 1 {#alterations-from-v2}

Toleo hili linarekebisha kutofautiana kadhaa na toleo la 1 lililochapishwa [hapa](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst). Kwa ufupi haya ni:

- Matumizi ya herufi kubwa hayana msingi na hayana msimamo (scrypt herufi ndogo, Kdf mchanganyiko, MAC herufi kubwa).
- Anwani sio ya lazima na inahatarisha faragha.
- `Chumvi` kimsingi ni kigezo cha kitendakazi cha kupata ufunguo na inastahili kuhusishwa nacho, sio na kripto kwa ujumla.
- _SaltLen_ sio ya lazima (ipate tu kutoka kwa Chumvi).
- Kitendakazi cha kupata ufunguo kimetolewa, lakini algoriti ya kripto imebainishwa kwa ukali.
- `Toleo` kimsingi ni nambari lakini ni mfuatano (utoaji toleo uliopangwa ungewezekana na mfuatano, lakini unaweza kuzingatiwa kuwa nje ya wigo wa umbizo la faili la usanidi linalobadilika mara chache).
- `KDF` na `cipher` ni dhana ndugu kinadharia lakini zimepangwa tofauti.
- `MAC` inakokotolewa kupitia kipande cha data kisichojali nafasi tupu(!)

Mabadiliko yamefanywa kwenye umbizo ili kutoa faili ifuatayo, ambayo ni sawa kiutendaji na mfano uliotolewa kwenye ukurasa uliounganishwa hapo awali:

```json
{
"crypto": {
"cipher": "aes-128-cbc",
"ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b",
"cipherparams": {
"iv": "16d67ba0ce5a339ff2f07951253e6ba8"
},
"kdf": "scrypt",
"kdfparams": {
"dklen": 32,
"n": 262144,
"p": 1,
"r": 8,
"salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91"
},
"mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd",
"version": 1
},
"id": "0498f19a-59db-4d54-ac95-33901b4f1870",
"version": 2
}
```

## Mabadiliko kutoka Toleo la 2 {#alterations-from-v2}

Toleo la 2 lilikuwa utekelezaji wa mapema wa C++ na idadi ya hitilafu. Mambo yote muhimu hayajabadilika kutoka humo.
Loading