ਖਾਤਾ-ਆਧਾਰਿਤ ਬਲਾਕਚੈਨ ਵਿੱਚ ਗੁਮਨਾਮਤਾ ਬਾਰੇ

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

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

ਇਹਨਾਂ ਡਾਟਾ ਮਾਡਲਾਂ ਦੀ ਬਣਤਰ ਬਾਰੇ

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

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

ਤਕਨਾਲੋਜੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ

ਅੱਗੇ, ਅਸੀਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ ਕਿ Zether ਲੈਣ-ਦੇਣ ਦੀ ਰਕਮ, ਪ੍ਰਾਪਤਕਰਤਾ ਅਤੇ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਕਿਵੇਂ ਲੁਕਾਉਂਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਇਸਦੇ ਸੰਚਾਲਨ ਦੇ ਸਿਧਾਂਤਾਂ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਗੁਪਤ ਅਤੇ ਅਗਿਆਤ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਅੰਤਰ ਨੂੰ ਨੋਟ ਕਰਾਂਗੇ। ਕਿਉਂਕਿ ਖਾਤਾ-ਆਧਾਰਿਤ ਬਲਾਕਚੈਨਾਂ ਵਿੱਚ ਗੁਪਤਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਬਹੁਤ ਸੌਖਾ ਹੈ, ਗੁਮਨਾਮਕਰਨ ਦੁਆਰਾ ਲਗਾਈਆਂ ਗਈਆਂ ਕੁਝ ਪਾਬੰਦੀਆਂ ਤਕਨਾਲੋਜੀ ਦੇ ਗੁਪਤ ਸੰਸਕਰਣ ਲਈ ਢੁਕਵੇਂ ਨਹੀਂ ਹੋਣਗੀਆਂ।

ਬਕਾਇਆ ਅਤੇ ਟ੍ਰਾਂਸਫਰ ਰਕਮਾਂ ਨੂੰ ਲੁਕਾਉਣਾ

ਇੱਕ ਏਨਕ੍ਰਿਪਸ਼ਨ ਸਕੀਮ ਦੀ ਵਰਤੋਂ Zether ਵਿੱਚ ਬੈਲੇਂਸ ਨੂੰ ਏਨਕ੍ਰਿਪਟ ਕਰਨ ਅਤੇ ਰਕਮਾਂ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਐਲ ਗਮਾਲ. ਇਹ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਐਲਿਸ ਬੌਬ ਨੂੰ ਭੇਜਣਾ ਚਾਹੁੰਦੀ ਹੈ b ਪਤੇ ਦੁਆਰਾ ਸਿੱਕੇ (ਇਸਦੀ ਜਨਤਕ ਕੁੰਜੀ) Y, ਉਹ ਇੱਕ ਬੇਤਰਤੀਬ ਨੰਬਰ ਚੁਣਦੀ ਹੈ r ਅਤੇ ਰਕਮ ਨੂੰ ਏਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ:

ਜਿੱਥੇ C - ਏਨਕ੍ਰਿਪਟਡ ਰਕਮ, D - ਇਸ ਰਕਮ ਨੂੰ ਸਮਝਣ ਲਈ ਜ਼ਰੂਰੀ ਸਹਾਇਕ ਮੁੱਲ, G - ਅੰਡਾਕਾਰ ਕਰਵ 'ਤੇ ਇੱਕ ਸਥਿਰ ਬਿੰਦੂ, ਜਦੋਂ ਗੁਪਤ ਕੁੰਜੀ ਨਾਲ ਗੁਣਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜਨਤਕ ਕੁੰਜੀ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ।

ਜਦੋਂ ਬੌਬ ਇਹਨਾਂ ਮੁੱਲਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਇਨਕ੍ਰਿਪਟਡ ਬੈਲੇਂਸ ਵਿੱਚ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਜੋੜਦਾ ਹੈ, ਜਿਸ ਕਰਕੇ ਇਹ ਸਕੀਮ ਸੁਵਿਧਾਜਨਕ ਹੈ।

ਇਸੇ ਤਰ੍ਹਾਂ, ਐਲਿਸ ਆਪਣੇ ਸੰਤੁਲਨ ਵਿੱਚੋਂ ਇੱਕੋ ਜਿਹੇ ਮੁੱਲਾਂ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ Y ਤੁਹਾਡੀ ਜਨਤਕ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਪ੍ਰਾਪਤਕਰਤਾ ਅਤੇ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਲੁਕਾਉਣਾ

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

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

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

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

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

ਲੈਣ-ਦੇਣ ਦੀਆਂ ਦੌੜ

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

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

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

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

ਇਹ ਹੱਲ ਗੁਪਤ ਟ੍ਰਾਂਸਫਰ ਲਈ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਅਗਿਆਤ ਲੈਣ-ਦੇਣ ਦੇ ਨਾਲ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਦੇਖਾਂਗੇ, ਇਹ ਗੰਭੀਰ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਰੀਪਲੇਅ ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਆ

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

ਇਸ ਹਮਲੇ ਨੂੰ ਰੀਪਲੇਅ ਅਟੈਕ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। UTXO ਮਾਡਲ ਵਿੱਚ, ਅਜਿਹੇ ਹਮਲੇ ਢੁਕਵੇਂ ਨਹੀਂ ਹਨ, ਕਿਉਂਕਿ ਹਮਲਾਵਰ ਖਰਚ ਕੀਤੇ ਆਉਟਪੁੱਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ, ਜੋ ਆਪਣੇ ਆਪ ਵਿੱਚ ਵੈਧ ਨਹੀਂ ਹੈ ਅਤੇ ਨੈੱਟਵਰਕ ਦੁਆਰਾ ਰੱਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ।

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

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

ਜ਼ੈਥਰ ਦੇ ਲੇਖਕ "ਯੁਗ" 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤੌਰ 'ਤੇ ਨਾਨਸ ਬਣਾਉਣ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਣ ਲਈ:

ਇਹ ਇਸ ਲਈ ਹੈ x ਭੇਜਣ ਵਾਲੇ ਦੀ ਗੁਪਤ ਕੁੰਜੀ ਹੈ, ਅਤੇ ਗੇਪੋਚ - ਯੁੱਗ ਲਈ ਇੱਕ ਵਾਧੂ ਜਨਰੇਟਰ, ਫਾਰਮ 'Zether +' ਦੀ ਇੱਕ ਸਤਰ ਨੂੰ ਹੈਸ਼ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ। ਹੁਣ ਸਮੱਸਿਆ ਹੱਲ ਹੋ ਗਈ ਜਾਪਦੀ ਹੈ - ਅਸੀਂ ਭੇਜਣ ਵਾਲੇ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਨੂੰ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰਦੇ ਹਾਂ ਅਤੇ ਗੈਰ-ਸ਼ਾਮਲ ਹੋਏ ਭਾਗੀਦਾਰਾਂ ਦੀਆਂ ਗੈਰ-ਸੰਬੰਧੀ ਗੱਲਾਂ ਵਿੱਚ ਦਖਲ ਨਹੀਂ ਦਿੰਦੇ ਹਾਂ। ਪਰ ਇਹ ਪਹੁੰਚ ਇੱਕ ਗੰਭੀਰ ਸੀਮਾ ਲਗਾਉਂਦੀ ਹੈ: ਇੱਕ ਖਾਤਾ ਪ੍ਰਤੀ "ਯੁਗ" ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਲੈਣ-ਦੇਣ ਨਹੀਂ ਭੇਜ ਸਕਦਾ ਹੈ। ਇਹ ਸਮੱਸਿਆ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਅਣਸੁਲਝੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਵਰਤਮਾਨ ਵਿੱਚ Zether ਦਾ ਅਗਿਆਤ ਸੰਸਕਰਣ ਬਣਾਉਂਦਾ ਹੈ, ਸਾਡੀ ਰਾਏ ਵਿੱਚ, ਵਰਤੋਂ ਲਈ ਮੁਸ਼ਕਿਲ ਨਾਲ ਢੁਕਵਾਂ ਹੈ.

ਜ਼ੀਰੋ ਗਿਆਨ ਪ੍ਰਮਾਣਾਂ ਦੀ ਗੁੰਝਲਤਾ

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

ਖਾਤਾ-ਆਧਾਰਿਤ ਬਲਾਕਚੈਨ ਦੇ ਅਗਿਆਤ ਸੰਸਕਰਣ ਵਿੱਚ, ਸਬੂਤ ਲਈ ਸਮੀਕਰਨ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਹਨ। ਭੇਜਣ ਵਾਲਾ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ:

1. ਭੇਜੀ ਗਈ ਰਕਮ ਸਕਾਰਾਤਮਕ ਹੈ;
2. ਸੰਤੁਲਨ ਗੈਰ-ਨੈਗੇਟਿਵ ਰਹਿੰਦਾ ਹੈ;
3. ਭੇਜਣ ਵਾਲੇ ਨੇ ਟ੍ਰਾਂਸਫਰ ਰਕਮਾਂ (ਜ਼ੀਰੋ ਸਮੇਤ) ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਹੈ;
4. ਬਕਾਇਆ 'ਤੇ ਬਕਾਇਆ ਸਿਰਫ ਭੇਜਣ ਵਾਲੇ ਅਤੇ ਪ੍ਰਾਪਤਕਰਤਾ ਲਈ ਬਦਲਦਾ ਹੈ;
5. ਭੇਜਣ ਵਾਲੇ ਕੋਲ ਆਪਣੇ ਖਾਤੇ ਦੀ ਨਿੱਜੀ ਕੁੰਜੀ ਹੈ ਅਤੇ ਉਹ ਅਸਲ ਵਿੱਚ ਭੇਜਣ ਵਾਲਿਆਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਹੈ (ਜੋ ਸ਼ਾਮਲ ਹਨ);
6. ਲੈਣ-ਦੇਣ ਵਿੱਚ ਵਰਤੀ ਗਈ Nonce ਸਹੀ ਢੰਗ ਨਾਲ ਬਣੀ ਹੈ।

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

ਅੰਤ ਵਿੱਚ ਕੀ?

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

ਸਰੋਤ: www.habr.com