---
title: "सिम्पल सीरियलाइज"
description: "इथेरियमच्या SSZ फॉरमॅटचे स्पष्टीकरण."
lang: mr
sidebarDepth: 2
---

**सिम्पल सीरियलाइज (SSZ)** ही बीकन साखळीवर वापरली जाणारी क्रमिकरण पद्धत आहे. ती अंमलबजावणी स्तरावर वापरल्या जाणाऱ्या RLP क्रमिकरणाची जागा घेते आणि पीअर शोध प्रोटोकॉल वगळता संपूर्ण सहमती स्तरावर वापरली जाते. RLP क्रमिकरणाबद्दल अधिक जाणून घेण्यासाठी, [रिकर्सिव्ह-लेंग्थ प्रीफिक्स (RLP)](/developers/docs/data-structures-and-encoding/rlp/) पहा. SSZ हे डिटरमिनिस्टिक (निश्चित) असण्यासाठी आणि कार्यक्षमतेने मर्कलाइज करण्यासाठी डिझाइन केले आहे. SSZ चे दोन घटक आहेत असे मानता येईल: एक क्रमिकरण योजना आणि एक मर्कलायझेशन योजना जी क्रमिकृत डेटा स्ट्रक्चरसह कार्यक्षमतेने कार्य करण्यासाठी डिझाइन केलेली आहे.

## SSZ कसे काम करते? {#how-does-ssz-work}

### क्रमिकरण {#serialization}

SSZ ही एक क्रमिकरण योजना आहे जी स्व-वर्णनात्मक नाही - त्याऐवजी ती एका स्कीमावर अवलंबून असते जी आगाऊ माहित असणे आवश्यक आहे. SSZ क्रमिकरणाचे ध्येय अनियंत्रित गुंतागुंतीच्या ऑब्जेक्ट्सना बाइट्सच्या स्ट्रिंग म्हणून दर्शवणे हे आहे. "मूलभूत प्रकारांसाठी" ही एक अतिशय सोपी प्रक्रिया आहे. घटक फक्त हेक्साडेसिमल बाइट्समध्ये रूपांतरित केला जातो. मूलभूत प्रकारांमध्ये हे समाविष्ट आहे:

- अनसाइन्ड इंटिजर्स (unsigned integers)
- बुलियन्स (Booleans)

गुंतागुंतीच्या "कंपोझिट" प्रकारांसाठी, क्रमिकरण अधिक क्लिष्ट असते कारण कंपोझिट प्रकारात अनेक घटक असतात ज्यांचे प्रकार किंवा आकार भिन्न असू शकतात किंवा दोन्ही भिन्न असू शकतात. जेथे या सर्व ऑब्जेक्ट्सची लांबी निश्चित असते (म्हणजेच, घटकांचा आकार त्यांच्या वास्तविक मूल्यांची पर्वा न करता नेहमी स्थिर राहील) तेथे क्रमिकरण म्हणजे कंपोझिट प्रकारातील प्रत्येक घटकाचे लिटल-एंडियन बाइटस्ट्रिंग्समध्ये क्रमाने केलेले साधे रूपांतरण असते. या बाइटस्ट्रिंग्स एकत्र जोडल्या जातात. क्रमिकृत ऑब्जेक्टमध्ये निश्चित-लांबीच्या घटकांचे बाइटलिस्ट सादरीकरण त्याच क्रमाने असते ज्या क्रमाने ते डीसीरियलाइज्ड ऑब्जेक्टमध्ये दिसतात.

बदलत्या लांबीच्या प्रकारांसाठी, क्रमिकृत ऑब्जेक्टमधील त्या घटकाच्या स्थानावर वास्तविक डेटा एका "ऑफसेट" मूल्याने बदलला जातो. वास्तविक डेटा क्रमिकृत ऑब्जेक्टच्या शेवटी एका ढिगाऱ्यात (heap) जोडला जातो. ऑफसेट मूल्य हे ढिगाऱ्यातील वास्तविक डेटाच्या सुरुवातीचा निर्देशांक असते, जे संबंधित बाइट्ससाठी पॉइंटर म्हणून कार्य करते.

खालील उदाहरण निश्चित आणि बदलत्या-लांबीचे दोन्ही घटक असलेल्या कंटेनरसाठी ऑफसेटिंग कसे कार्य करते हे स्पष्ट करते:

```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` ची रचना खालीलप्रमाणे असेल (येथे फक्त 4 बिट्सपर्यंत पॅड केलेले आहे, प्रत्यक्षात 32 बिट्सपर्यंत पॅड केलेले असते, आणि स्पष्टतेसाठी `int` सादरीकरण ठेवले आहे):

```
[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4]
------------  -----------  -----------  -----------  ----------
      |             |            |           |            |
   number1       number2    vector साठी   number 3    vector चे
                              offset                    मूल्य
```

स्पष्टतेसाठी ओळींमध्ये विभागलेले:

```
[
  37, 0, 0, 0,  # `number1` चे लिटल-एंडियन एन्कोडिंग.
  55, 0, 0, 0,  # `number2` चे लिटल-एंडियन एन्कोडिंग.
  16, 0, 0, 0,  # "ऑफसेट" जे दर्शवते की `vector` चे मूल्य कोठे सुरू होते (लिटल-एंडियन 16).
  22, 0, 0, 0,  # `number3` चे लिटल-एंडियन एन्कोडिंग.
  1, 2, 3, 4,   # `vector` मधील वास्तविक मूल्ये.
]
```

हे अद्याप एक साधे रूप आहे - वरील आकृतीमधील इंटिजर्स आणि शून्य प्रत्यक्षात बाइटलिस्ट म्हणून संग्रहित केले जातील, याप्रमाणे:

```
[
  10100101000000000000000000000000  # `number1` चे लिटल-एंडियन एन्कोडिंग
  10110111000000000000000000000000  # `number2` चे लिटल-एंडियन एन्कोडिंग.
  10010000000000000000000000000000  # "ऑफसेट" जे दर्शवते की `vector` चे मूल्य कोठे सुरू होते (लिटल-एंडियन 16).
  10010110000000000000000000000000  # `number3` चे लिटल-एंडियन एन्कोडिंग.
  10000001100000101000001110000100   # `bytes` फील्डचे वास्तविक मूल्य.
]
```

म्हणून बदलत्या-लांबीच्या प्रकारांसाठी वास्तविक मूल्ये क्रमिकृत ऑब्जेक्टच्या शेवटी एका ढिगाऱ्यात (heap) संग्रहित केली जातात आणि त्यांचे ऑफसेट्स फील्ड्सच्या क्रमित सूचीमध्ये त्यांच्या योग्य स्थानांवर संग्रहित केले जातात.

काही विशेष प्रकरणे देखील आहेत ज्यांना विशिष्ट उपचारांची आवश्यकता असते, जसे की `BitList` प्रकार ज्यामध्ये क्रमिकरणादरम्यान लांबीची मर्यादा (length cap) जोडणे आणि डीसीरियलायझेशन दरम्यान ती काढून टाकणे आवश्यक असते. संपूर्ण तपशील [SSZ स्पेक](https://github.com/ethereum/consensus-specs/blob/master/ssz/simple-serialize.md) मध्ये उपलब्ध आहेत.

### डीसीरियलायझेशन {#deserialization}

या ऑब्जेक्टला डीसीरियलाइज करण्यासाठी <b>स्कीमा</b> आवश्यक आहे. स्कीमा क्रमिकृत डेटाचा अचूक लेआउट परिभाषित करतो जेणेकरून प्रत्येक विशिष्ट घटक बाइट्सच्या ब्लॉबमधून योग्य प्रकार, मूल्य, आकार आणि स्थान असलेल्या काही अर्थपूर्ण ऑब्जेक्टमध्ये डीसीरियलाइज केला जाऊ शकतो. स्कीमाच डीसीरियलायझरला सांगतो की कोणती मूल्ये वास्तविक मूल्ये आहेत आणि कोणती ऑफसेट्स आहेत. जेव्हा एखादा ऑब्जेक्ट क्रमिकृत केला जातो तेव्हा सर्व फील्ड नावे नाहीशी होतात, परंतु स्कीमानुसार डीसीरियलायझेशनवर ती पुन्हा स्थापित केली जातात.
## मर्कलायझेशन {#merkleization}

हा SSZ क्रमिकृत ऑब्जेक्ट नंतर मर्कलाइज केला जाऊ शकतो - म्हणजेच त्याच डेटाच्या मर्कल ट्री सादरीकरणात रूपांतरित केला जाऊ शकतो. प्रथम, क्रमिकृत ऑब्जेक्टमधील 32-बाइट चंक्सची संख्या निश्चित केली जाते. ही ट्रीची "पाने (leaves)" आहेत. पानांची एकूण संख्या 2 च्या घातांकात असणे आवश्यक आहे जेणेकरून पानांचे एकत्र हॅशिंग केल्याने शेवटी एकच हॅश-ट्री-रूट तयार होईल. जर नैसर्गिकरित्या असे नसेल, तर शून्यांचे 32 बाइट्स असलेली अतिरिक्त पाने जोडली जातात. आकृतीच्या स्वरूपात:

```
हॅश ट्री रूट
            /     \
           /       \
          /         \
         /           \
   पानांचा हॅश     पानांचा हॅश
     1 आणि 2         3 आणि 4
      /   \            /  \
     /     \          /    \
    /       \        /      \
 leaf1     leaf2  leaf3     leaf4
```

अशीही काही प्रकरणे आहेत जिथे ट्रीची पाने वरील उदाहरणाप्रमाणे नैसर्गिकरित्या समान रीतीने वितरीत होत नाहीत. उदाहरणार्थ, leaf 4 हा अनेक घटक असलेला कंटेनर असू शकतो ज्यासाठी मर्कल ट्रीमध्ये अतिरिक्त "खोली (depth)" जोडणे आवश्यक असते, ज्यामुळे एक असमान ट्री तयार होते.

या ट्री घटकांना leaf X, नोड X इत्यादी म्हणून संदर्भित करण्याऐवजी, आपण त्यांना सामान्यीकृत निर्देशांक देऊ शकतो, ज्याची सुरुवात root = 1 पासून होते आणि प्रत्येक स्तरावर डावीकडून उजवीकडे मोजले जाते. हा वर स्पष्ट केलेला सामान्यीकृत निर्देशांक आहे. क्रमिकृत सूचीतील प्रत्येक घटकाचा सामान्यीकृत निर्देशांक `2**depth + idx` च्या समान असतो जेथे idx हे क्रमिकृत ऑब्जेक्टमधील त्याचे शून्य-निर्देशांकित स्थान असते आणि खोली (depth) ही मर्कल ट्रीमधील स्तरांची संख्या असते, जी घटकांच्या (पानांच्या) संख्येचा बेस-टू लॉगरिथम म्हणून निश्चित केली जाऊ शकते.

## सामान्यीकृत निर्देशांक {#generalized-indices}

सामान्यीकृत निर्देशांक हा एक इंटिजर असतो जो बायनरी मर्कल ट्रीमधील नोड दर्शवतो जेथे प्रत्येक नोडचा सामान्यीकृत निर्देशांक `2 ** depth + index in row` असतो.

```
1           --खोली = 0  2**0 + 0 = 1
    2       3       --खोली = 1  2**1 + 0 = 2, 2**1+1 = 3
  4   5   6   7     --खोली = 2  2**2 + 0 = 4, 2**2 + 1 = 5...
```

हे सादरीकरण मर्कल ट्रीमधील डेटाच्या प्रत्येक भागासाठी नोड निर्देशांक देते.

## मल्टीप्रूफ्स {#multiproofs}

एखाद्या विशिष्ट घटकाचे प्रतिनिधित्व करणाऱ्या सामान्यीकृत निर्देशांकांची सूची प्रदान केल्याने आपल्याला हॅश-ट्री-रूटच्या विरूद्ध त्याची पडताळणी करण्याची अनुमती मिळते. हे रूट आपली वास्तवाची स्वीकारलेली आवृत्ती आहे. आपल्याला प्रदान केलेला कोणताही डेटा मर्कल ट्रीमध्ये योग्य ठिकाणी (त्याच्या सामान्यीकृत निर्देशांकाद्वारे निर्धारित) समाविष्ट करून आणि रूट स्थिर राहतो हे पाहून त्या वास्तवाच्या विरूद्ध सत्यापित केला जाऊ शकतो. स्पेक मध्ये [येथे](https://github.com/ethereum/consensus-specs/blob/master/ssz/merkle-proofs.md#merkle-multiproofs) अशी फंक्शन्स आहेत जी सामान्यीकृत निर्देशांकांच्या विशिष्ट संचातील सामग्री सत्यापित करण्यासाठी आवश्यक असलेल्या नोड्सचा किमान संच कसा मोजायचा हे दर्शवतात.

उदाहरणार्थ, खालील ट्रीमध्ये निर्देशांक 9 मधील डेटा सत्यापित करण्यासाठी, आपल्याला 8, 9, 5, 3, 1 निर्देशांकांवरील डेटाचा हॅश आवश्यक आहे.
(8,9) चा हॅश हॅश (4) च्या समान असावा, जो 5 सह हॅश होऊन 2 तयार करतो, जो 3 सह हॅश होऊन ट्री रूट 1 तयार करतो. जर 9 साठी चुकीचा डेटा प्रदान केला गेला असेल, तर रूट बदलेल - आपण हे शोधून काढू आणि शाखा सत्यापित करण्यात अयशस्वी होऊ.

```
* = पुरावा तयार करण्यासाठी आवश्यक डेटा

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

## पुढील वाचन {#further-reading}

- [अपग्रेडिंग इथेरियम: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz)
- [अपग्रेडिंग इथेरियम: मर्कलायझेशन](https://eth2book.info/altair/part2/building_blocks/merkleization)
- [SSZ अंमलबजावणी](https://github.com/ethereum/consensus-specs/issues/2138)
- [SSZ कॅल्क्युलेटर](https://simpleserialize.com/)