ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਦੂਜੇ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਕੀ ਬੇਤਰਤੀਬ ਨੰਬਰ ਬਣਾਉਣਾ ਸੰਭਵ ਹੈ? ਭਾਗ 1

ਹੇ ਹਬਰ!

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

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

ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਵੰਡਿਆ ਹੋਇਆ ਬੇਤਰਤੀਬ ਨੰਬਰ ਬਣਾਉਣ ਦਾ ਪ੍ਰੋਟੋਕੋਲ ਤਿਆਰ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਇਸ ਵਿੱਚ ਤਿੰਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹੋਣ:

1. ਉਸਨੂੰ ਨਿਰਪੱਖ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਕਿਸੇ ਵੀ ਭਾਗੀਦਾਰ ਨੂੰ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਬੇਤਰਤੀਬ ਨੰਬਰ ਜਨਰੇਟਰ ਦੇ ਨਤੀਜੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

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

3. ਪ੍ਰੋਟੋਕੋਲ ਵਿਹਾਰਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵ, ਇਸ ਤੱਥ ਦੇ ਪ੍ਰਤੀ ਰੋਧਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਭਾਗੀਦਾਰਾਂ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਪ੍ਰਤੀਸ਼ਤ ਨੈਟਵਰਕ ਤੋਂ ਡਿਸਕਨੈਕਟ ਹੋ ਜਾਂਦੀ ਹੈ ਜਾਂ ਜਾਣਬੁੱਝ ਕੇ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਰੋਕਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ।

ਇਸ ਲੇਖ ਵਿੱਚ ਅਸੀਂ ਦੋ ਪਹੁੰਚਾਂ ਨੂੰ ਦੇਖਾਂਗੇ: RANDAO + VDF ਅਤੇ ਇਰੇਜ਼ਰ ਕੋਡ ਪਹੁੰਚ। ਅਗਲੇ ਭਾਗ ਵਿੱਚ, ਅਸੀਂ ਥ੍ਰੈਸ਼ਹੋਲਡ ਦਸਤਖਤਾਂ ਦੇ ਅਧਾਰ ਤੇ ਪਹੁੰਚ ਦੀ ਵਿਸਤਾਰ ਵਿੱਚ ਜਾਂਚ ਕਰਾਂਗੇ।

ਪਰ ਪਹਿਲਾਂ, ਆਓ ਇੱਕ ਸਧਾਰਨ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਐਲਗੋਰਿਦਮ ਨੂੰ ਵੇਖੀਏ ਜੋ ਵਿਵਹਾਰਕ, ਅਸੰਭਵ, ਪਰ ਪੱਖਪਾਤੀ ਹੈ।

ਰੰਡਾਓ

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

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

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

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

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

RANDAO+VDF

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

(vdf_output, vdf_proof) = VDF_compute(input) // это очень медленно
correct = VDF_verify(input, vdf_output, vdf_proof) // это очень быстро

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

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

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

ਉੱਪਰ ਦੱਸੇ ਗਏ VDF ਪਰਿਵਾਰ ਲਈ, ਇੱਕ ਸਮਰਪਿਤ ASIC ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਰਵਾਇਤੀ ਹਾਰਡਵੇਅਰ ਨਾਲੋਂ 100+ ਗੁਣਾ ਵੱਧ ਹੋ ਸਕਦੀ ਹੈ। ਇਸ ਲਈ ਜੇਕਰ ਖੁਲਾਸਾ ਪੜਾਅ 10 ਸਕਿੰਟ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਅਜਿਹੇ ASIC 'ਤੇ ਗਣਨਾ ਕੀਤੀ ਗਈ VDF ਨੂੰ 100x ਸੁਰੱਖਿਆ ਮਾਰਜਿਨ ਹੋਣ ਲਈ 10 ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਕਮੋਡਿਟੀ ਹਾਰਡਵੇਅਰ 'ਤੇ ਗਣਨਾ ਕੀਤੇ ਗਏ VDF ਨੂੰ 100x 100 ਸਕਿੰਟ = ~ 3 ਘੰਟੇ ਲੱਗਣੇ ਚਾਹੀਦੇ ਹਨ।

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

VDF ਬਾਰੇ ਬਹੁਤ ਸਾਰੇ ਲੇਖ, ਵੀਡੀਓ ਅਤੇ ਹੋਰ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕੀਤੀ ਗਈ ਹੈ ਇਹ ਸਾਈਟ.

ਅਸੀਂ ਇਰੇਜ਼ਰ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ

ਇਸ ਭਾਗ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਬੇਤਰਤੀਬ ਨੰਬਰ ਬਣਾਉਣ ਵਾਲੇ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਵੇਖਾਂਗੇ ਜੋ ਵਰਤਦਾ ਹੈ ਕੋਡਾਂ ਨੂੰ ਮਿਟਾਉਣਾ. ਇਹ ਵਿਵਹਾਰਕ ਰਹਿੰਦੇ ਹੋਏ ⅓ ਹਮਲਾਵਰਾਂ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਨਤੀਜੇ ਦੀ ਭਵਿੱਖਬਾਣੀ ਜਾਂ ਪ੍ਰਭਾਵਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ⅔ ਹਮਲਾਵਰਾਂ ਨੂੰ ਮੌਜੂਦ ਰਹਿਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਇਸ ਪ੍ਰਕਾਰ ਹੈ। ਸਰਲਤਾ ਲਈ, ਮੰਨ ਲਓ ਕਿ ਇੱਥੇ ਬਿਲਕੁਲ 100 ਭਾਗੀਦਾਰ ਹਨ। ਆਓ ਇਹ ਵੀ ਮੰਨੀਏ ਕਿ ਸਾਰੇ ਭਾਗੀਦਾਰਾਂ ਕੋਲ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕੁਝ ਨਿੱਜੀ ਕੁੰਜੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸਾਰੇ ਭਾਗੀਦਾਰਾਂ ਦੀਆਂ ਜਨਤਕ ਕੁੰਜੀਆਂ ਸਾਰੇ ਭਾਗੀਦਾਰਾਂ ਨੂੰ ਜਾਣੀਆਂ ਜਾਂਦੀਆਂ ਹਨ:

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

2. ਭਾਗੀਦਾਰ ਖਾਸ 67 ਭਾਗੀਦਾਰਾਂ ਤੋਂ ਕੋਡ ਕੀਤੇ ਸੈੱਟਾਂ 'ਤੇ ਸਮਝੌਤੇ 'ਤੇ ਪਹੁੰਚਣ ਲਈ ਕਿਸੇ ਕਿਸਮ ਦੀ ਸਹਿਮਤੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

3. ਇੱਕ ਵਾਰ ਸਹਿਮਤੀ ਬਣ ਜਾਣ 'ਤੇ, ਹਰੇਕ ਭਾਗੀਦਾਰ ਆਪਣੀ ਜਨਤਕ ਕੁੰਜੀ ਨਾਲ ਏਨਕ੍ਰਿਪਟ ਕੀਤੇ 67 ਸੈੱਟਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਏਨਕੋਡ ਕੀਤੇ ਸ਼ੇਅਰ ਲੈਂਦਾ ਹੈ, ਅਜਿਹੇ ਸਾਰੇ ਸ਼ੇਅਰਾਂ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਜਿਹੇ ਸਾਰੇ ਡੀਕ੍ਰਿਪਟ ਕੀਤੇ ਸ਼ੇਅਰਾਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ।

4. ਇੱਕ ਵਾਰ ਜਦੋਂ 67 ਭਾਗੀਦਾਰਾਂ ਨੇ ਪੜਾਅ (3) ਪੂਰਾ ਕਰ ਲਿਆ ਹੈ, ਤਾਂ ਸਾਰੇ ਸਹਿਮਤ ਹੋਏ ਸੈੱਟਾਂ ਨੂੰ ਮਿਟਾਉਣ ਵਾਲੇ ਕੋਡਾਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਕਾਰਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡੀਕੋਡ ਅਤੇ ਪੁਨਰਗਠਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਅੰਤਮ ਸੰਖਿਆ ਸ਼ੁਰੂਆਤੀ ਕਤਾਰਾਂ ਦੇ ਇੱਕ XOR ਵਜੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਜਿਸ ਨਾਲ ਭਾਗੀਦਾਰਾਂ ਨੇ (1) ਵਿੱਚ ਸ਼ੁਰੂਆਤ ਕੀਤੀ ਸੀ। .

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

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

ਜਦੋਂ ਪੜਾਅ (4) ਵਿੱਚ ਭਾਗੀਦਾਰ ਇੱਕ ਖਾਸ ਸਟ੍ਰਿੰਗ ਲਈ 67 ਬੀਟਸ ਨੂੰ ਸਮਝਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਤੋਂ ਅਸਲ ਸਤਰ ਨੂੰ ਮੁੜ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੰਭਵ ਹੈ:

1. ਸਤਰ ਨੂੰ ਮੁੜ ਬਹਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਇਸਨੂੰ ਦੁਬਾਰਾ ਮਿਟਾਇਆ-ਏਨਕੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮਰਕਲ ਟ੍ਰੀ ਦੀ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਗਣਨਾ ਕੀਤੇ ਸ਼ੇਅਰਾਂ ਲਈ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਰੂਟ ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਸਹਿਮਤੀ ਬਣੀ ਸੀ।

2. ਕਤਾਰ ਰੀਸਟੋਰ ਕੀਤੀ ਗਈ ਹੈ, ਪਰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਗਣਨਾ ਕੀਤੀ ਗਈ ਰੂਟ ਉਸ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ ਜਿਸ 'ਤੇ ਸਹਿਮਤੀ ਬਣੀ ਸੀ।

3. ਕਤਾਰ ਬਹਾਲ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ।

ਇਹ ਦਿਖਾਉਣਾ ਆਸਾਨ ਹੈ ਕਿ ਜੇਕਰ ਵਿਕਲਪ (1) ਉਪਰੋਕਤ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਭਾਗੀਦਾਰ ਲਈ ਹੋਇਆ ਹੈ, ਤਾਂ ਵਿਕਲਪ (1) ਸਾਰੇ ਭਾਗੀਦਾਰਾਂ ਲਈ ਹੋਇਆ ਹੈ, ਅਤੇ ਇਸਦੇ ਉਲਟ, ਜੇਕਰ ਵਿਕਲਪ (2) ਜਾਂ (3) ਘੱਟੋ-ਘੱਟ ਇੱਕ ਭਾਗੀਦਾਰ ਲਈ ਹੋਇਆ ਹੈ, ਤਾਂ ਸਾਰੇ ਭਾਗੀਦਾਰਾਂ ਲਈ ਵਿਕਲਪ (2) ਜਾਂ (3) ਹੋਵੇਗਾ। ਇਸ ਤਰ੍ਹਾਂ, ਸੈੱਟ ਵਿੱਚ ਹਰੇਕ ਕਤਾਰ ਲਈ, ਜਾਂ ਤਾਂ ਸਾਰੇ ਭਾਗੀਦਾਰ ਇਸਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰ ਲੈਣਗੇ, ਜਾਂ ਸਾਰੇ ਭਾਗੀਦਾਰ ਇਸਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਹੋ ਜਾਣਗੇ। ਨਤੀਜੇ ਵਜੋਂ ਬੇਤਰਤੀਬ ਸੰਖਿਆ ਕੇਵਲ ਉਹਨਾਂ ਕਤਾਰਾਂ ਦਾ ਇੱਕ XOR ਹੈ ਜੋ ਭਾਗੀਦਾਰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਸਨ।

ਥ੍ਰੈਸ਼ਹੋਲਡ ਦਸਤਖਤ

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

BLS ਦਸਤਖਤ ਇੱਕ ਡਿਜ਼ਾਇਨ ਹਨ ਜੋ ਕਈ ਭਾਗੀਦਾਰਾਂ ਨੂੰ ਇੱਕ ਸੰਦੇਸ਼ ਲਈ ਇੱਕ ਸਾਂਝੇ ਦਸਤਖਤ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇਹਨਾਂ ਦਸਤਖਤਾਂ ਦੀ ਵਰਤੋਂ ਅਕਸਰ ਸਪੇਸ ਅਤੇ ਬੈਂਡਵਿਡਥ ਨੂੰ ਬਚਾਉਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਕਈ ਦਸਤਖਤਾਂ ਨੂੰ ਬਾਹਰ ਭੇਜਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। 

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

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

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

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

ਅੰਤ ਵਿੱਚ

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

ਪ੍ਰੋਟੋਕੋਲ ਕੋਡ ਖੁੱਲ੍ਹਾ ਹੈ, ਸਾਡਾ ਲਾਗੂਕਰਨ Rust ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਇਹ ਲੱਭਿਆ ਜਾ ਸਕਦਾ ਹੈ ਇੱਥੇ.

ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ NEAR ਲਈ ਵਿਕਾਸ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਅਤੇ ਔਨਲਾਈਨ IDE ਵਿੱਚ ਪ੍ਰਯੋਗ ਕਰ ਸਕਦੇ ਹੋ ਇੱਥੇ.

ਤੁਸੀਂ ਰੂਸੀ ਵਿੱਚ ਸਾਰੀਆਂ ਖ਼ਬਰਾਂ ਦੀ ਪਾਲਣਾ ਕਰ ਸਕਦੇ ਹੋ ਟੈਲੀਗ੍ਰਾਮ ਗਰੁੱਪ ਅਤੇ ਅੰਦਰ VKontakte 'ਤੇ ਗਰੁੱਪ, ਅਤੇ ਅਧਿਕਾਰੀ ਵਿੱਚ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਟਵਿੱਟਰ.

ਜਲਦੀ ਮਿਲਦੇ ਹਾਂ!

ਸਰੋਤ: www.habr.com