ਟਨ: ਟੈਲੀਗ੍ਰਾਮ ਓਪਨ ਨੈੱਟਵਰਕ। ਭਾਗ 2: ਬਲਾਕਚੈਨ, ਸ਼ਰਡਿੰਗ

ਇਹ ਟੈਕਸਟ ਲੇਖਾਂ ਦੀ ਇੱਕ ਲੜੀ ਦੀ ਇੱਕ ਨਿਰੰਤਰਤਾ ਹੈ ਜਿਸ ਵਿੱਚ ਮੈਂ (ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ) ਵੰਡੇ ਨੈਟਵਰਕ ਟੈਲੀਗ੍ਰਾਮ ਓਪਨ ਨੈਟਵਰਕ (TON) ਦੀ ਬਣਤਰ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹਾਂ, ਜੋ ਇਸ ਸਾਲ ਰਿਲੀਜ਼ ਲਈ ਤਿਆਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ। IN ਪਿਛਲੇ ਭਾਗ ਮੈਂ ਇਸਦੇ ਸਭ ਤੋਂ ਬੁਨਿਆਦੀ ਪੱਧਰ ਦਾ ਵਰਣਨ ਕੀਤਾ - ਨੋਡਸ ਇੱਕ ਦੂਜੇ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਦਾ ਤਰੀਕਾ.

ਸਿਰਫ਼ ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਮੈਂ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਮੇਰਾ ਇਸ ਨੈਟਵਰਕ ਦੇ ਵਿਕਾਸ ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਹੈ ਅਤੇ ਸਾਰੀ ਸਮੱਗਰੀ ਇੱਕ ਖੁੱਲੇ (ਹਾਲਾਂਕਿ ਗੈਰ-ਪ੍ਰਮਾਣਿਤ) ਸਰੋਤ ਤੋਂ ਇਕੱਠੀ ਕੀਤੀ ਗਈ ਸੀ - ਦਸਤਾਵੇਜ਼ (ਇੱਕ ਸਾਥ ਵੀ ਹੈ ਬਰੋਸ਼ਰ, ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ ਮੁੱਖ ਬਿੰਦੂਆਂ ਦੀ ਰੂਪਰੇਖਾ), ਜੋ ਪਿਛਲੇ ਸਾਲ ਦੇ ਅੰਤ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਏ ਸਨ। ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਜਾਣਕਾਰੀ ਦੀ ਮਾਤਰਾ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਇਸਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ, ਹਾਲਾਂਕਿ ਇਸਦੀ ਕੋਈ ਅਧਿਕਾਰਤ ਪੁਸ਼ਟੀ ਨਹੀਂ ਹੈ।

ਅੱਜ ਅਸੀਂ TON ਦੇ ਮੁੱਖ ਹਿੱਸੇ - ਬਲਾਕਚੈਨ ਨੂੰ ਦੇਖਾਂਗੇ।

ਬੁਨਿਆਦੀ ਧਾਰਨਾ

ਖਾਤਾ (ਖਾਤੇ). ਇੱਕ 256-ਬਿੱਟ ਨੰਬਰ ਦੁਆਰਾ ਪਛਾਣੇ ਗਏ ਡੇਟਾ ਦਾ ਇੱਕ ਸਮੂਹ ਖਾਤਾ ID (ਅਕਸਰ ਇਹ ਖਾਤਾ ਮਾਲਕ ਦੀ ਜਨਤਕ ਕੁੰਜੀ ਹੁੰਦੀ ਹੈ)। ਬੇਸ ਕੇਸ ਵਿੱਚ (ਹੇਠਾਂ ਦੇਖੋ ਜ਼ੀਰੋ ਵਰਕਚੇਨ), ਇਹ ਡੇਟਾ ਉਪਭੋਗਤਾ ਦੇ ਸੰਤੁਲਨ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਖਾਸ "ਕਬਜ਼ਾ ਕਰੋ" ਖਾਤਾ ID ਕੋਈ ਵੀ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਸਦਾ ਮੁੱਲ ਸਿਰਫ ਕੁਝ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਸਮਾਰਟ ਇਕਰਾਰਨਾਮਾ (ਸਮਾਰਟ-ਇਕਰਾਰਨਾਮਾ). ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ, ਇਹ ਇੱਕ ਖਾਤੇ ਦਾ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕੇਸ ਹੈ, ਜੋ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਕੋਡ ਅਤੇ ਇਸਦੇ ਵੇਰੀਏਬਲਾਂ ਦੇ ਸਟੋਰੇਜ ਨਾਲ ਪੂਰਕ ਹੈ। ਜੇਕਰ "ਵਾਲਿਟ" ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਤੁਸੀਂ ਮੁਕਾਬਲਤਨ ਸਧਾਰਨ ਅਤੇ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ ਇਸ ਵਿੱਚੋਂ ਪੈਸੇ ਜਮ੍ਹਾ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਕਢਵਾ ਸਕਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਇਹ ਨਿਯਮ ਇਸਦੇ ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਲਿਖੇ ਗਏ ਹਨ (ਇੱਕ ਖਾਸ ਟਿਊਰਿੰਗ-ਪੂਰੀ ਵਿੱਚ. ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ).

ਬਲਾਕਚੈਨ ਰਾਜ (ਬਲਾਕਚੈਨ ਦੀ ਸਥਿਤੀ). ਸਾਰੇ ਖਾਤਿਆਂ/ਸਮਾਰਟ ਇਕਰਾਰਨਾਮਿਆਂ ਦੀਆਂ ਸਥਿਤੀਆਂ ਦਾ ਸੈੱਟ (ਇੱਕ ਸੰਖੇਪ ਅਰਥਾਂ ਵਿੱਚ, ਇੱਕ ਹੈਸ਼ ਟੇਬਲ, ਜਿੱਥੇ ਕੁੰਜੀਆਂ ਖਾਤਾ ਪਛਾਣਕਰਤਾ ਹਨ ਅਤੇ ਮੁੱਲ ਖਾਤਿਆਂ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਡੇਟਾ ਹਨ)।

ਸੁਨੇਹਾ (ਸੁਨੇਹੇ ਨੂੰ). ਉੱਪਰ ਮੈਂ "ਕ੍ਰੈਡਿਟ ਅਤੇ ਡੈਬਿਟ ਮਨੀ" ਸਮੀਕਰਨ ਦੀ ਵਰਤੋਂ ਕੀਤੀ - ਇਹ ਇੱਕ ਸੰਦੇਸ਼ ਦੀ ਇੱਕ ਖਾਸ ਉਦਾਹਰਣ ਹੈ ("ਟ੍ਰਾਂਸਫਰ N ਗ੍ਰਾਮ ਖਾਤੇ ਤੋਂ ਖਾਤਾ_1 ਖਾਤੇ ਵਿੱਚ ਖਾਤਾ_2"). ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਸਿਰਫ ਨੋਡ ਜੋ ਖਾਤੇ ਦੀ ਨਿੱਜੀ ਕੁੰਜੀ ਦਾ ਮਾਲਕ ਹੈ, ਅਜਿਹਾ ਸੁਨੇਹਾ ਭੇਜ ਸਕਦਾ ਹੈ ਖਾਤਾ_1 - ਅਤੇ ਇੱਕ ਦਸਤਖਤ ਨਾਲ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੇ ਯੋਗ। ਅਜਿਹੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਇੱਕ ਨਿਯਮਤ ਖਾਤੇ ਵਿੱਚ ਪਹੁੰਚਾਉਣ ਦਾ ਨਤੀਜਾ ਇਸਦੇ ਬਕਾਏ ਵਿੱਚ ਵਾਧਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਦਾ ਨਤੀਜਾ ਇਸਦੇ ਕੋਡ (ਜੋ ਸੁਨੇਹੇ ਦੀ ਰਸੀਦ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰੇਗਾ) ਦਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਹੈ। ਬੇਸ਼ੱਕ, ਹੋਰ ਸੁਨੇਹੇ ਵੀ ਸੰਭਵ ਹਨ (ਮੌਦਰਿਕ ਰਕਮਾਂ ਦਾ ਤਬਾਦਲਾ ਨਹੀਂ, ਪਰ ਸਮਾਰਟ ਕੰਟਰੈਕਟਸ ਦੇ ਵਿਚਕਾਰ ਆਪਹੁਦਰੇ ਡੇਟਾ)।

ਲੈਣ-ਦੇਣ (ਸੰਚਾਰ). ਇਹ ਤੱਥ ਕਿ ਇੱਕ ਸੁਨੇਹਾ ਡਿਲੀਵਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਇੱਕ ਲੈਣ-ਦੇਣ ਕਿਹਾ ਜਾਂਦਾ ਹੈ. ਲੈਣ-ਦੇਣ ਬਲਾਕਚੈਨ ਦੀ ਸਥਿਤੀ ਨੂੰ ਬਦਲਦਾ ਹੈ। ਇਹ ਲੈਣ-ਦੇਣ (ਸੁਨੇਹਾ ਡਿਲੀਵਰੀ ਰਿਕਾਰਡ) ਹੈ ਜੋ ਬਲਾਕਚੈਨ ਵਿੱਚ ਬਲਾਕ ਬਣਾਉਂਦੇ ਹਨ। ਇਸ ਸਬੰਧ ਵਿੱਚ, ਤੁਸੀਂ ਬਲਾਕਚੈਨ ਦੀ ਸਥਿਤੀ ਨੂੰ ਇੱਕ ਵਾਧੇ ਵਾਲੇ ਡੇਟਾਬੇਸ ਦੇ ਰੂਪ ਵਿੱਚ ਸੋਚ ਸਕਦੇ ਹੋ - ਸਾਰੇ ਬਲਾਕ "ਡਿਫਸ" ਹਨ ਜੋ ਡੇਟਾਬੇਸ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕ੍ਰਮਵਾਰ ਲਾਗੂ ਕੀਤੇ ਜਾਣ ਦੀ ਲੋੜ ਹੈ। ਇਹਨਾਂ "ਡਿਫਸ" (ਅਤੇ ਇਹਨਾਂ ਤੋਂ ਪੂਰੀ ਸਥਿਤੀ ਨੂੰ ਬਹਾਲ ਕਰਨ) ਦੀ ਪੈਕਿੰਗ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਾਰੇ ਅਗਲੇ ਲੇਖ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ।

TON ਵਿੱਚ ਬਲਾਕਚੈਨ: ਇਹ ਕੀ ਹੈ ਅਤੇ ਕਿਉਂ?

ਜਿਵੇਂ ਕਿ ਪਿਛਲੇ ਲੇਖ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਬਲਾਕਚੈਨ ਇੱਕ ਡੇਟਾ ਢਾਂਚਾ ਹੈ, ਜਿਸ ਦੇ ਤੱਤ (ਬਲਾਕ) ਨੂੰ ਇੱਕ "ਚੇਨ" ਵਿੱਚ ਆਰਡਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਚੇਨ ਦੇ ਹਰੇਕ ਅਗਲੇ ਬਲਾਕ ਵਿੱਚ ਪਿਛਲੇ ਇੱਕ ਦੀ ਇੱਕ ਹੈਸ਼ ਹੁੰਦੀ ਹੈ।. ਟਿੱਪਣੀਆਂ ਨੇ ਸਵਾਲ ਪੁੱਛਿਆ: ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ DHT - ਇੱਕ ਡਿਸਟਰੀਬਿਊਟਿਡ ਹੈਸ਼ ਟੇਬਲ ਹੈ ਤਾਂ ਸਾਨੂੰ ਅਜਿਹੇ ਡੇਟਾ ਢਾਂਚੇ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ? ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਕੁਝ ਡੇਟਾ DHT ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਸਿਰਫ "ਸੰਵੇਦਨਸ਼ੀਲ" ਜਾਣਕਾਰੀ ਲਈ ਢੁਕਵਾਂ ਹੈ. Cryptocurrency ਬੈਲੰਸ ਨੂੰ DHT ਵਿੱਚ ਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ - ਮੁੱਖ ਤੌਰ 'ਤੇ ਜਾਂਚਾਂ ਦੀ ਘਾਟ ਕਾਰਨ ਇਮਾਨਦਾਰੀ. ਅਸਲ ਵਿੱਚ, ਬਲਾਕਚੈਨ ਢਾਂਚੇ ਦੀ ਸਾਰੀ ਗੁੰਝਲਤਾ ਇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਡੇਟਾ ਵਿੱਚ ਦਖਲਅੰਦਾਜ਼ੀ ਨੂੰ ਰੋਕਣ ਲਈ ਵਧਦੀ ਹੈ।

ਹਾਲਾਂਕਿ, TON ਵਿੱਚ ਬਲਾਕਚੈਨ ਜ਼ਿਆਦਾਤਰ ਹੋਰ ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਸਿਸਟਮਾਂ ਨਾਲੋਂ ਵੀ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ - ਅਤੇ ਦੋ ਕਾਰਨਾਂ ਕਰਕੇ। ਪਹਿਲੀ ਲੋੜ ਨੂੰ ਘੱਟ ਕਰਨ ਦੀ ਇੱਛਾ ਹੈ ਕਾਂਟੇ. ਰਵਾਇਤੀ ਕ੍ਰਿਪਟੋਕਰੰਸੀ ਵਿੱਚ, ਸਾਰੇ ਮਾਪਦੰਡ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਸੈੱਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਦਲਣ ਦੀ ਕੋਈ ਵੀ ਕੋਸ਼ਿਸ਼ ਅਸਲ ਵਿੱਚ ਇੱਕ "ਵਿਕਲਪਕ ਕ੍ਰਿਪਟੋਕਰੰਸੀ ਬ੍ਰਹਿਮੰਡ" ਦੇ ਉਭਾਰ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ। ਦੂਜਾ ਕਾਰਨ ਕੁਚਲਣ ਲਈ ਸਮਰਥਨ ਹੈ (ਸ਼ਾਰਡਿੰਗ, ਸ਼ਾਰਡਿੰਗ) ਬਲਾਕਚੈਨ. ਬਲਾਕਚੈਨ ਇੱਕ ਢਾਂਚਾ ਹੈ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਛੋਟਾ ਨਹੀਂ ਹੋ ਸਕਦਾ; ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਨੈੱਟਵਰਕ ਦੇ ਸੰਚਾਲਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਰੇਕ ਨੋਡ ਨੂੰ ਇਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਟੋਰ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਰਵਾਇਤੀ (ਕੇਂਦਰੀਕ੍ਰਿਤ) ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ, ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਸ਼ਾਰਡਿੰਗ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ: ਡੇਟਾਬੇਸ ਵਿੱਚ ਕੁਝ ਰਿਕਾਰਡ ਇੱਕ ਸਰਵਰ 'ਤੇ ਸਥਿਤ ਹੁੰਦੇ ਹਨ, ਕੁਝ ਦੂਜੇ 'ਤੇ, ਆਦਿ। ਕ੍ਰਿਪਟੋਕੁਰੰਸੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਅਜਿਹੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਅਜੇ ਵੀ ਬਹੁਤ ਘੱਟ ਹੈ - ਖਾਸ ਤੌਰ 'ਤੇ, ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਇੱਕ ਸਿਸਟਮ ਵਿੱਚ ਸ਼ਾਰਡਿੰਗ ਜੋੜਨਾ ਮੁਸ਼ਕਲ ਹੈ ਜਿੱਥੇ ਇਹ ਅਸਲ ਵਿੱਚ ਯੋਜਨਾਬੱਧ ਨਹੀਂ ਸੀ.

TON ਉਪਰੋਕਤ ਦੋਵਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਯੋਜਨਾ ਕਿਵੇਂ ਬਣਾਉਂਦਾ ਹੈ?

ਬਲਾਕਚੈਨ ਸਮੱਗਰੀ। ਵਰਕਚੇਨ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਆਓ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰੀਏ ਕਿ ਬਲਾਕਚੈਨ ਵਿੱਚ ਕੀ ਸਟੋਰ ਕਰਨ ਦੀ ਯੋਜਨਾ ਹੈ। ਖਾਤਿਆਂ ਦੀਆਂ ਸਥਿਤੀਆਂ (ਬੇਸ ਕੇਸ ਵਿੱਚ "ਵਾਲਿਟ") ਅਤੇ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਉੱਥੇ ਸਟੋਰ ਕੀਤੇ ਜਾਣਗੇ (ਸਰਲਤਾ ਲਈ, ਅਸੀਂ ਮੰਨ ਲਵਾਂਗੇ ਕਿ ਇਹ ਖਾਤਿਆਂ ਵਾਂਗ ਹੀ ਹੈ)। ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ, ਇਹ ਇੱਕ ਨਿਯਮਤ ਹੈਸ਼ ਟੇਬਲ ਹੋਵੇਗਾ - ਇਸ ਵਿੱਚ ਕੁੰਜੀਆਂ ਪਛਾਣਕਰਤਾ ਹੋਣਗੀਆਂ ਖਾਤਾ ID, ਅਤੇ ਮੁੱਲ ਡੇਟਾ ਢਾਂਚੇ ਹਨ ਜਿਹਨਾਂ ਵਿੱਚ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਹਨ:

• ਸੰਤੁਲਨ;
• ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਕੋਡ (ਸਿਰਫ਼ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਲਈ);
• ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਡਾਟਾ ਸਟੋਰੇਜ (ਸਿਰਫ਼ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਲਈ);
• ਅੰਕੜੇ;
• (ਵਿਕਲਪਿਕ) ਖਾਤੇ ਤੋਂ ਟ੍ਰਾਂਸਫਰ ਲਈ ਜਨਤਕ ਕੁੰਜੀ, ਮੂਲ ਰੂਪ ਵਿੱਚ account_id;
• ਆਊਟਗੋਇੰਗ ਸੁਨੇਹਿਆਂ ਦੀ ਕਤਾਰ (ਇੱਥੇ ਉਹ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਲਈ ਦਾਖਲ ਕੀਤੇ ਗਏ ਹਨ);
• ਇਸ ਖਾਤੇ ਨੂੰ ਦਿੱਤੇ ਗਏ ਨਵੀਨਤਮ ਸੁਨੇਹਿਆਂ ਦੀ ਸੂਚੀ।

ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਬਲਾਕਾਂ ਵਿੱਚ ਆਪਣੇ ਆਪ ਵਿੱਚ ਲੈਣ-ਦੇਣ ਹੁੰਦੇ ਹਨ - ਵੱਖ-ਵੱਖ account_id ਖਾਤਿਆਂ ਨੂੰ ਦਿੱਤੇ ਗਏ ਸੁਨੇਹੇ। ਹਾਲਾਂਕਿ, account_id ਤੋਂ ਇਲਾਵਾ, ਸੁਨੇਹਿਆਂ ਵਿੱਚ ਇੱਕ 32-ਬਿੱਟ ਖੇਤਰ ਵੀ ਹੁੰਦਾ ਹੈ workchain_id - ਅਖੌਤੀ ਪਛਾਣਕਰਤਾ ਵਰਕਚੇਨ (ਵਰਕਚੇਨ, ਬਲਾਕਚੈਨ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ). ਇਹ ਤੁਹਾਨੂੰ ਵੱਖ-ਵੱਖ ਸੰਰਚਨਾਵਾਂ ਦੇ ਨਾਲ ਇੱਕ ਦੂਜੇ ਤੋਂ ਸੁਤੰਤਰ ਕਈ ਬਲਾਕਚੈਨ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਸ ਕੇਸ ਵਿੱਚ, workchain_id = 0 ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕੇਸ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਜ਼ੀਰੋ ਵਰਕਚੇਨ - ਇਹ ਇਸ ਵਿੱਚ ਬਕਾਇਆ ਹੈ ਜੋ TON (ਗ੍ਰਾਮ) ਕ੍ਰਿਪਟੋਕੁਰੰਸੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਪਹਿਲਾਂ, ਹੋਰ ਵਰਕਚੇਨ ਬਿਲਕੁਲ ਮੌਜੂਦ ਨਹੀਂ ਹੋਣਗੇ.

ਸ਼ਾਰਡਚੇਨ। ਅਨੰਤ ਸ਼ਾਰਡਿੰਗ ਪੈਰਾਡਾਈਮ।

ਪਰ ਬਲਾਕਚੈਨ ਦੀ ਗਿਣਤੀ ਵਿੱਚ ਵਾਧਾ ਉੱਥੇ ਨਹੀਂ ਰੁਕਦਾ. ਆਉ ਸ਼ਾਰਡਿੰਗ ਨਾਲ ਨਜਿੱਠੀਏ. ਚਲੋ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਹਰੇਕ ਖਾਤੇ (account_id) ਨੂੰ ਇਸਦਾ ਆਪਣਾ ਬਲਾਕਚੈਨ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ - ਇਸ ਵਿੱਚ ਉਹ ਸਾਰੇ ਸੰਦੇਸ਼ ਸ਼ਾਮਲ ਹਨ ਜੋ ਇਸ ਵਿੱਚ ਆਉਂਦੇ ਹਨ - ਅਤੇ ਅਜਿਹੇ ਸਾਰੇ ਬਲਾਕਚੈਨ ਦੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਵੱਖਰੇ ਨੋਡਾਂ 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਬੇਸ਼ੱਕ, ਇਹ ਬਹੁਤ ਫਾਲਤੂ ਹੈ: ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਸ਼ਾਰਡਚੇਨ (ਸ਼ਾਰਡਚੇਨ, ਸ਼ਾਰਡ ਬਲਾਕਚੈਨ) ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਬਹੁਤ ਘੱਟ ਹੀ ਆਉਣਗੇ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਨੋਡਾਂ ਦੀ ਲੋੜ ਪਵੇਗੀ (ਅੱਗੇ ਦੇਖਦੇ ਹੋਏ, ਮੈਂ ਨੋਟ ਕਰਦਾ ਹਾਂ ਕਿ ਅਸੀਂ ਸਿਰਫ ਮੋਬਾਈਲ ਫੋਨਾਂ 'ਤੇ ਗਾਹਕਾਂ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰ ਰਹੇ ਹਾਂ - ਪਰ ਗੰਭੀਰ ਸਰਵਰਾਂ ਬਾਰੇ).

ਇਸ ਲਈ, ਸ਼ਾਰਡਚੈਨ ਆਪਣੇ ਪਛਾਣਕਰਤਾਵਾਂ ਦੇ ਬਾਈਨਰੀ ਅਗੇਤਰਾਂ ਦੁਆਰਾ ਖਾਤਿਆਂ ਨੂੰ ਜੋੜਦੀਆਂ ਹਨ: ਜੇਕਰ ਇੱਕ ਸ਼ਾਰਡਚੇਨ ਦਾ ਅਗੇਤਰ 0110 ਹੈ, ਤਾਂ ਇਸ ਵਿੱਚ ਇਹਨਾਂ ਨੰਬਰਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਸਾਰੇ account_ids ਦੇ ਲੈਣ-ਦੇਣ ਸ਼ਾਮਲ ਹੋਣਗੇ। ਇਹ shard_prefix ਦੀ ਲੰਬਾਈ 0 ਤੋਂ 60 ਬਿੱਟ ਤੱਕ ਹੋ ਸਕਦੀ ਹੈ - ਅਤੇ ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ।

ਜਿਵੇਂ ਹੀ ਸ਼ਾਰਡਚੇਨ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਲੈਣ-ਦੇਣ ਪ੍ਰਾਪਤ ਹੋਣੇ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਨੋਡ, ਪੂਰਵ-ਨਿਰਧਾਰਤ ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ, ਇਸਨੂੰ ਦੋ ਬੱਚਿਆਂ ਵਿੱਚ ਵੰਡਦੇ ਹਨ - ਉਹਨਾਂ ਦੇ ਅਗੇਤਰ ਇੱਕ ਬਿੱਟ ਲੰਬੇ ਹੋਣਗੇ (ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਲਈ ਇਹ ਬਿੱਟ ਹੋਵੇਗਾ। 0 ਦੇ ਬਰਾਬਰ, ਅਤੇ ਦੂਜੇ ਲਈ - 1)। ਉਦਾਹਰਣ ਲਈ, shard_prefix = 0110b ਵਿੱਚ ਵੰਡਿਆ ਜਾਵੇਗਾ 01100ਬੀ ਅਤੇ 01101ਬੀ. ਬਦਲੇ ਵਿੱਚ, ਜੇ ਦੋ "ਗੁਆਂਢੀ" ਸ਼ਾਰਡਚੇਨ ਕਾਫ਼ੀ ਆਰਾਮਦਾਇਕ ਮਹਿਸੂਸ ਕਰਨ ਲੱਗਦੀਆਂ ਹਨ (ਕੁਝ ਸਮੇਂ ਲਈ), ਉਹ ਦੁਬਾਰਾ ਮਿਲ ਜਾਣਗੀਆਂ।

ਇਸ ਤਰ੍ਹਾਂ, ਸ਼ਾਰਡਿੰਗ "ਤਲ ਤੋਂ ਉੱਪਰ" ਕੀਤੀ ਜਾਂਦੀ ਹੈ - ਅਸੀਂ ਮੰਨਦੇ ਹਾਂ ਕਿ ਹਰੇਕ ਖਾਤੇ ਦਾ ਆਪਣਾ ਸ਼ਾਰਡ ਹੁੰਦਾ ਹੈ, ਪਰ ਕੁਝ ਸਮੇਂ ਲਈ ਉਹ ਅਗੇਤਰਾਂ ਦੁਆਰਾ "ਇਕੱਠੇ ਚਿਪਕਾਏ" ਹੁੰਦੇ ਹਨ। ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਅਨੰਤ ਸ਼ਾਰਡਿੰਗ ਪੈਰਾਡਾਈਮ (ਅਨੰਤ ਸ਼ਾਰਡਿੰਗ ਪੈਰਾਡਾਈਮ).

ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਮੈਂ ਇਸ ਗੱਲ 'ਤੇ ਜ਼ੋਰ ਦੇਣਾ ਚਾਹਾਂਗਾ ਕਿ ਵਰਕਚੇਨ ਸਿਰਫ ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਹਨ - ਅਸਲ ਵਿੱਚ, workchain_id ਇਹ ਇੱਕ ਖਾਸ ਸ਼ਾਰਡਚੇਨ ਦੇ ਪਛਾਣਕਰਤਾ ਦਾ ਹਿੱਸਾ ਹੈ। ਰਸਮੀ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਹਰੇਕ ਸ਼ਾਰਡਚੇਨ ਨੂੰ ਸੰਖਿਆਵਾਂ ਦੇ ਇੱਕ ਜੋੜੇ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (workchain_id, shard_prefix).

ਗਲਤੀ ਸੁਧਾਰ। ਵਰਟੀਕਲ ਬਲਾਕਚੈਨ।

ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ, ਬਲਾਕਚੈਨ 'ਤੇ ਕਿਸੇ ਵੀ ਲੈਣ-ਦੇਣ ਨੂੰ "ਪੱਥਰ ਵਿੱਚ ਸੈੱਟ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ, TON ਦੇ ਮਾਮਲੇ ਵਿੱਚ, "ਇਤਿਹਾਸ ਨੂੰ ਮੁੜ ਲਿਖਣਾ" ਸੰਭਵ ਹੈ - ਜੇਕਰ ਕੋਈ ਵਿਅਕਤੀ (ਅਖੌਤੀ. ਮਛੇਰੇ ਗੰਢ) ਸਾਬਤ ਕਰੇਗਾ ਕਿ ਬਲਾਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਉੱਤੇ ਗਲਤ ਦਸਤਖਤ ਕੀਤੇ ਗਏ ਸਨ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸੰਬੰਧਿਤ ਸ਼ਾਰਡਚੇਨ ਵਿੱਚ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸੁਧਾਰ ਬਲਾਕ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਬਲਾਕ ਦੇ ਹੈਸ਼ ਨੂੰ ਖੁਦ ਠੀਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਨਾ ਕਿ ਸ਼ਾਰਡਚੇਨ ਵਿੱਚ ਆਖਰੀ ਬਲਾਕ)। ਸ਼ਾਰਡਚੇਨ ਨੂੰ ਖਿਤਿਜੀ ਤੌਰ 'ਤੇ ਰੱਖੇ ਗਏ ਬਲਾਕਾਂ ਦੀ ਇੱਕ ਲੜੀ ਦੇ ਰੂਪ ਵਿੱਚ ਸੋਚਦੇ ਹੋਏ, ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਸੁਧਾਰਾਤਮਕ ਬਲਾਕ ਗਲਤ ਬਲਾਕ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ ਸੱਜੇ ਪਾਸੇ ਨਹੀਂ, ਪਰ ਉੱਪਰ ਤੋਂ - ਇਸ ਲਈ ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਇਹ ਇੱਕ ਛੋਟੇ "ਲੰਬਕਾਰੀ ਬਲਾਕਚੈਨ" ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ। . ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਸ਼ਾਰਡਚੇਨ ਹਨ ਦੋ-ਅਯਾਮੀ ਬਲਾਕਚੈਨ.

ਜੇਕਰ, ਇੱਕ ਗਲਤ ਬਲਾਕ ਦੇ ਬਾਅਦ, ਇਸ ਦੁਆਰਾ ਕੀਤੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਬਾਅਦ ਦੇ ਬਲਾਕਾਂ ਦੁਆਰਾ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਸੀ (ਅਰਥਾਤ, ਅਵੈਧ ਲੋਕਾਂ ਦੇ ਅਧਾਰ ਤੇ ਨਵੇਂ ਲੈਣ-ਦੇਣ ਕੀਤੇ ਗਏ ਸਨ), ਸੁਧਾਰਾਤਮਕ ਵੀ ਇਹਨਾਂ ਬਲਾਕਾਂ ਵਿੱਚ "ਉੱਪਰ" ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਜੇਕਰ ਬਲਾਕਾਂ ਨੇ "ਪ੍ਰਭਾਵਿਤ" ਜਾਣਕਾਰੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕੀਤਾ, ਤਾਂ ਇਹ "ਸੁਧਾਰਕ ਤਰੰਗਾਂ" ਉਹਨਾਂ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਉਪਰੋਕਤ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਵਿੱਚ, ਪਹਿਲੇ ਬਲਾਕ ਦੇ ਲੈਣ-ਦੇਣ, ਖਾਤੇ C ਦੇ ਬਕਾਏ ਨੂੰ ਵਧਾਉਣਾ, ਨੂੰ ਗਲਤ ਮੰਨਿਆ ਗਿਆ ਸੀ - ਇਸ ਲਈ, ਤੀਜੇ ਬਲਾਕ ਵਿੱਚ ਇਸ ਖਾਤੇ ਦੇ ਬਕਾਏ ਨੂੰ ਘਟਾਉਣ ਵਾਲੇ ਲੈਣ-ਦੇਣ ਨੂੰ ਵੀ ਰੱਦ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਸੁਧਾਰਾਤਮਕ ਬਲਾਕ ਬਲਾਕ ਦੇ ਸਿਖਰ 'ਤੇ ਪ੍ਰਤੀਬੱਧ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ.

ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹਾਲਾਂਕਿ ਸੁਧਾਰਾਤਮਕ ਬਲਾਕਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ "ਉੱਪਰ" ਸਥਿਤ ਵਜੋਂ ਦਰਸਾਇਆ ਗਿਆ ਹੈ, ਅਸਲ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਸੰਬੰਧਿਤ ਬਲਾਕਚੈਨ ਦੇ ਅੰਤ ਵਿੱਚ ਜੋੜਿਆ ਜਾਵੇਗਾ (ਜਿੱਥੇ ਉਹਨਾਂ ਨੂੰ ਕਾਲਕ੍ਰਮ ਅਨੁਸਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ)। ਦੋ-ਅਯਾਮੀ ਟਿਕਾਣਾ ਸਿਰਫ਼ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਬਲਾਕਚੈਨ ਦੇ ਕਿਹੜੇ ਬਿੰਦੂ 'ਤੇ ਉਹ "ਲਿੰਕ" ਹੋਣਗੇ (ਉਨ੍ਹਾਂ ਵਿੱਚ ਸਥਿਤ ਅਸਲ ਬਲਾਕ ਦੇ ਹੈਸ਼ ਦੁਆਰਾ)।

ਤੁਸੀਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦਰਸ਼ਨ ਕਰ ਸਕਦੇ ਹੋ ਕਿ "ਅਤੀਤ ਨੂੰ ਬਦਲਣ" ਦਾ ਫੈਸਲਾ ਕਿੰਨਾ ਚੰਗਾ ਹੈ। ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ ਜੇਕਰ ਅਸੀਂ ਸ਼ਾਰਡਚੇਨ ਵਿੱਚ ਇੱਕ ਗਲਤ ਬਲਾਕ ਦੇ ਦਿਖਾਈ ਦੇਣ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਗਲਤ ਸੁਧਾਰ ਬਲਾਕ ਦੇ ਪ੍ਰਗਟ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਤੋਂ ਬਚ ਨਹੀਂ ਸਕਦੇ। ਇੱਥੇ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਦੱਸ ਸਕਦਾ ਹਾਂ, ਅੰਤਰ ਨੋਡਾਂ ਦੀ ਸੰਖਿਆ ਵਿੱਚ ਹੈ ਜੋ ਨਵੇਂ ਬਲਾਕਾਂ 'ਤੇ ਸਹਿਮਤੀ ਤੱਕ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ - ਹਰੇਕ ਸ਼ਾਰਡਚੇਨ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਲੋਕਾਂ ਦੀ ਮੁਕਾਬਲਤਨ ਘੱਟ ਗਿਣਤੀ ਹੋਵੇਗੀ।"ਵਰਕਿੰਗ ਗਰੁੱਪ» ਨੋਡਸ (ਜੋ ਇਸਦੀ ਰਚਨਾ ਨੂੰ ਅਕਸਰ ਬਦਲਦਾ ਹੈ), ਅਤੇ ਸੁਧਾਰਾਤਮਕ ਬਲਾਕਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਲਈ ਹਰ ਕਿਸੇ ਦੀ ਸਹਿਮਤੀ ਦੀ ਲੋੜ ਪਵੇਗੀ ਵੈਲੀਡੇਟਰ ਨੋਡਸ. ਮੈਂ ਅਗਲੇ ਲੇਖ ਵਿੱਚ ਵੈਲੀਡੇਟਰਾਂ, ਵਰਕਗਰੁੱਪਾਂ ਅਤੇ ਹੋਰ ਨੋਡ ਰੋਲ ਬਾਰੇ ਹੋਰ ਗੱਲ ਕਰਾਂਗਾ।

ਉਹਨਾਂ ਸਾਰਿਆਂ 'ਤੇ ਰਾਜ ਕਰਨ ਲਈ ਇੱਕ ਬਲਾਕਚੈਨ

ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਬਲਾਕਚੈਨਾਂ ਬਾਰੇ ਉੱਪਰ ਸੂਚੀਬੱਧ ਬਹੁਤ ਸਾਰੀ ਜਾਣਕਾਰੀ ਹੈ, ਜਿਸ ਨੂੰ ਖੁਦ ਵੀ ਕਿਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਣਕਾਰੀ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ:

• ਵਰਕਚੇਨ ਦੀ ਸੰਖਿਆ ਅਤੇ ਸੰਰਚਨਾ ਬਾਰੇ;
• ਸ਼ਾਰਡਚੇਨ ਦੀ ਗਿਣਤੀ ਅਤੇ ਉਹਨਾਂ ਦੇ ਅਗੇਤਰ ਬਾਰੇ;
• ਇਸ ਬਾਰੇ ਕਿਹੜੇ ਨੋਡਸ ਇਸ ਸਮੇਂ ਕਿਹੜੇ ਸ਼ਾਰਡਚੇਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ;
• ਸਾਰੀਆਂ ਸ਼ਾਰਡਚੇਨਾਂ ਵਿੱਚ ਜੋੜੇ ਗਏ ਆਖਰੀ ਬਲਾਕਾਂ ਦੇ ਹੈਸ਼।

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਅਨੁਮਾਨ ਲਗਾਇਆ ਹੋਵੇਗਾ, ਇਹ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਇੱਕ ਹੋਰ ਬਲਾਕਚੈਨ ਸਟੋਰੇਜ ਵਿੱਚ ਰਿਕਾਰਡ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ - ਮਾਸਟਰਚੇਨ (ਮਾਸਟਰਚੇਨ, ਮਾਸਟਰ ਬਲਾਕਚੈਨ). ਇਸਦੇ ਬਲਾਕਾਂ ਵਿੱਚ ਸਾਰੇ ਸ਼ਾਰਡਚੇਨ ਦੇ ਬਲਾਕਾਂ ਤੋਂ ਹੈਸ਼ਾਂ ਦੀ ਮੌਜੂਦਗੀ ਦੇ ਕਾਰਨ, ਇਹ ਸਿਸਟਮ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਨੈਕਟ ਕਰਦਾ ਹੈ। ਇਸਦਾ ਅਰਥ ਹੈ, ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਇਹ ਕਿ ਮਾਸਟਰਚੇਨ ਵਿੱਚ ਇੱਕ ਨਵੇਂ ਬਲਾਕ ਦੀ ਪੀੜ੍ਹੀ ਸ਼ਾਰਡਚੇਨ ਵਿੱਚ ਬਲਾਕਾਂ ਦੀ ਉਤਪੱਤੀ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਆਵੇਗੀ - ਇਹ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਸ਼ਾਰਡਚੇਨ ਵਿੱਚ ਬਲਾਕ ਲਗਭਗ ਹਰ 5 ਸਕਿੰਟਾਂ ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ ਦਿਖਾਈ ਦੇਣਗੇ, ਅਤੇ ਅਗਲੇ ਬਲਾਕ ਵਿੱਚ ਮਾਸਟਰਚੇਨ - ਉਸ ਤੋਂ ਬਾਅਦ ਇੱਕ ਸਕਿੰਟ।

ਪਰ ਇਸ ਸਾਰੇ ਟਾਇਟੈਨਿਕ ਕੰਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੋਵੇਗਾ - ਸੁਨੇਹੇ ਭੇਜਣ, ਸਮਾਰਟ ਕੰਟਰੈਕਟਸ ਨੂੰ ਲਾਗੂ ਕਰਨ, ਸ਼ਾਰਡਚੇਨ ਅਤੇ ਮਾਸਟਰਚੇਨ ਵਿੱਚ ਬਲਾਕ ਬਣਾਉਣ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਗਲਤੀਆਂ ਲਈ ਬਲਾਕਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ? ਕੀ ਇਹ ਸਭ ਕੁਝ ਲੱਖਾਂ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਫੋਨਾਂ ਦੁਆਰਾ ਗੁਪਤ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਟੈਲੀਗ੍ਰਾਮ ਕਲਾਇੰਟ ਸਥਾਪਤ ਕੀਤਾ ਜਾਵੇਗਾ? ਜਾਂ, ਸ਼ਾਇਦ, ਦੁਰੋਵ ਟੀਮ ਵਿਕੇਂਦਰੀਕਰਣ ਦੇ ਵਿਚਾਰਾਂ ਨੂੰ ਛੱਡ ਦੇਵੇਗੀ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸਰਵਰ ਇਸ ਨੂੰ ਪੁਰਾਣੇ ਜ਼ਮਾਨੇ ਦੇ ਤਰੀਕੇ ਨਾਲ ਕਰਨਗੇ?

ਅਸਲ ਵਿੱਚ, ਨਾ ਤਾਂ ਇੱਕ ਅਤੇ ਨਾ ਹੀ ਦੂਜਾ ਜਵਾਬ ਸਹੀ ਹੈ. ਪਰ ਇਸ ਲੇਖ ਦੇ ਹਾਸ਼ੀਏ ਤੇਜ਼ੀ ਨਾਲ ਖਤਮ ਹੋ ਰਹੇ ਹਨ, ਇਸਲਈ ਅਸੀਂ ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਨੋਡਾਂ ਦੀਆਂ ਵੱਖ ਵੱਖ ਭੂਮਿਕਾਵਾਂ (ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਦਾ ਜ਼ਿਕਰ ਪਹਿਲਾਂ ਹੀ ਦੇਖਿਆ ਹੋਵੇਗਾ), ਅਤੇ ਨਾਲ ਹੀ ਉਹਨਾਂ ਦੇ ਕੰਮ ਦੇ ਮਕੈਨਿਕਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ.

ਸਰੋਤ: www.habr.com