ਬਿਟਕਾਇਨ ਨੂੰ ਅਕਸਰ ਵਿਕਾਸ ਵਿੱਚ ਹੌਲੀ ਹੋਣ ਲਈ ਆਲੋਚਨਾ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਪਰ ਇਹ ਧਾਰਨਾ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਤਰੀਕੇ ਦੀ ਗਲਤ ਸਮਝ ਤੋਂ ਉਪਜਦੀ ਹੈ ਕਿ ਉਹ ਸੁਰੱਖਿਆ ਅਤੇ ਸਥਿਰਤਾ ਨੂੰ ਕਿਵੇਂ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ। ਹੋਰ ਬਲਾਕਚੇਨ ਨੈੱਟਵਰਕਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰੀਏ ਤਾਂ ਅਪਡੇਟ ਘੱਟ ਆਉਂਦੇ ਹਨ, ਪਰ ਜਦੋਂ ਆਉਂਦੇ ਹਨ ਤਾਂ ਡੂੰਘੇ ਪ੍ਰਭਾਵ ਵਾਲੇ ਹੁੰਦੇ ਹਨ। ਨਵੰਬਰ 2021 ਵਿੱਚ Taproot ਦਾ ਸਰਗਰਮੀਕਰਨ ਬਿਟਕਾਇਨ ਦੇ ਇਤਿਹਾਸ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਤਕਨੀਕੀ ਛਲਾਂਗਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ। ਇਹ ਅਪਗ੍ਰੇਡ ਸਿਰਫ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਸੀ ਬਲਕਿ ਉਹ ਤਕਨੀਕਾਂ ਦਾ ਬੰਡਲ ਸੀ ਜੋ ਲੈਣ-ਦੇਣਾਂ ਦੀ ਪ੍ਰਮਾਣਿਤੀ ਅਤੇ ਬਲਾਕਚੇਨ ਉੱਤੇ ਡਾਟਾ ਸਟੋਰੇਜ ਨੂੰ ਆਧੁਨਿਕ ਬਣਾਉਣ ਲਈ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ।
ਇਸ ਦੇ ਕੇਂਦਰ ਵਿੱਚ, Taproot ਦੋ ਮੁੱਢਲੀਆਂ ਚੁਣੌਤੀਆਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ: ਗੋਪਨੀਯਤਾ ਅਤੇ ਕੁਸ਼ਲਤਾ। ਜਿਵੇਂ-ਜਿਵੇਂ ਨੈੱਟਵਰਕ ਵਧਿਆ, ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੱਧ ਗੁੰਝਲਦਾਰ ਲੈਣ-ਦੇਣ ਵਰਗਾਂ ਦੀ ਮੰਗ ਕੀਤੀ, ਜਿਵੇਂ ਮਲਟੀ-ਸਿਗਨੇਚਰ ਵਾਲਟ ਅਤੇ ਸਮੇਂ ਨਾਲ ਬੰਨ੍ਹੇ ਕਰਾਰ। ਬਿਟਕਾਇਨ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਪਿਛਲੇ ਰੂਪ ਵਿੱਚ, ਇਹ ਗੁੰਝਲਦਾਰ ਲੈਣ-ਦੇਣ ਡਾਟਾ ਵਾਲੇ ਹੁੰਦੇ ਸਨ ਅਤੇ ਜਨਤਕ ਲੇਜਰ ਉੱਤੇ ਅਸਾਨੀ ਨਾਲ ਪਛਾਣੇ ਜਾਂਦੇ ਸਨ। ਇਸ ਨਾਲ ਉਪਭੋਕਤਾਵਾਂ ਨੂੰ ਉੱਨਤ ਸਕ੍ਰਿਪਟਿੰਗ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਰਤਣ ਲਈ ਗੋਪਨੀਯਤਾ ਦੀ ਬਲੀ ਚੜ੍ਹਾਉਣੀ ਪੈਂਦੀ ਅਤੇ ਵੱਧ ਫੀਸ ਅਦਾ ਕਰਨੀ ਪੈਂਦੀ।
Taproot ਅਪਗ੍ਰੇਡ Schnorr ਹਸਤਾਖਰਾਂ, Merkelized Abstract Syntax Trees (MAST), ਅਤੇ Tapscript ਨਾਮਕ ਨਵੀਂ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾ ਪੇਸ਼ ਕਰਕੇ ਇਹ ਮੁੱਦੇ ਹੱਲ ਕਰਦਾ ਹੈ। ਇਹ ਤਕਨੀਕਾਂ ਮਿਲ ਕੇ ਗੁੰਝਲਦਾਰ ਲੈਣ-ਦੇਣਾਂ ਨੂੰ ਬਲਾਕਚੇਨ ਉੱਤੇ ਸਟੈਂਡਰਡ ਟ੍ਰਾਂਸਫਰਾਂ ਵਾਂਗ ਅਗਵਾਈ ਅਣਪਛਾਤੀ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਇਹ ਇੱਕ ਵੱਧ ਗੋਪਨੀਯਤਾ ਵਾਲਾ, ਬਦਲਣਯੋਗ ਅਤੇ ਸਕੇਲੇਬਲ ਨੈੱਟਵਰਕ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਭਾਗ ਸਮਝਣ ਨਾਲ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਬਿਟਕਾਇਨ ਆਪਣੇ ਆਪ ਨੂੰ ਨਾ ਸਿਰਫ ਡਿਜੀਟਲ ਸੋਨੇ ਵਜੋਂ, ਸਗੋਂ ਸੁਰੱਖਿਅਤ, ਗੋਪਨੀਯ ਅਤੇ ਕੁਸ਼ਲ ਮੁੱਲ ਟ੍ਰਾਂਸਫਰ ਲਈ ਮਜ਼ਬੂਤ ਪਲੇਟਫਾਰਮ ਵਜੋਂ ਕਿਵੇਂ ਸਥਾਪਤ ਕਰ ਰਿਹਾ ਹੈ।
ਬਿਟਕਾਇਨ ਅਪਗ੍ਰੇਡਾਂ ਦਾ ਇਤਿਹਾਸਕ ਸੰਦਰਭ
Taproot ਦੀ ਮਹੱਤਤਾ ਨੂੰ ਸਮਝਣ ਲਈ, ਨੂੰ 2017 ਦੇ Segregated Witness (SegWit) ਅਪਗ੍ਰੇਡ ਵੱਲ ਵਾਪਸ ਵੇਖਣਾ ਪਵੇਗਾ। SegWit ਮੁੱਖ ਤੌਰ ਤੇ ਲੈਣ-ਦੇਣ malleability ਲਈ ਇੱਕ ਠੀਕ ਸੀ, ਇੱਕ ਬਗ ਜੋ ਪੁਸ਼ਟੀ ਤੋਂ ਪਹਿਲਾਂ ਲੈਣ-ਦੇਣ ID ਨੂੰ ਬਦਲਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਸੀ। ਹਾਲਾਂਕਿ, ਇਸ ਦੀ ਸਭ ਤੋਂ ਲੰਬੇ ਸਮੇਂ ਦੀ ਵਿਰਾਸਤ ਬਲਾਕ ਸਪੇਸ ਨੂੰ ਮਾਪਣ ਦੇ ਤਰੀਕੇ ਵਿੱਚ ਬਦਲਾਅ ਸੀ। ਡਿਜੀਟਲ ਹਸਤਾਖਰ (witness data) ਨੂੰ ਲੈਣ-ਦੇਣ ਡਾਟਾ ਤੋਂ ਵੱਖ ਕਰਕੇ, SegWit ਨੇ ਅਸਲ ਵਿੱਚ ਬਲਾਕ ਆਕਾਰ ਸੀਮਾ ਵਧਾ ਦਿੱਤੀ ਅਤੇ Lightning Network ਵਰਗੇ Layer-2 ਹੱਲਾਂ ਲਈ ਰਾਹ ਤਿਆਰ ਕੀਤਾ।
SegWit ਨੇ "ਬਲਾਕ ਵਜ਼ਨ" ਦੀ ਸੰਕਲਪਨਾ ਪੇਸ਼ ਕੀਤੀ, ਜਿਸ ਨਾਲ witness data ਦੇ ਆਕਾਰ ਨੂੰ ਘਟਾਉਂਦੇ ਹੋਏ ਇੱਕ ਬਲਾਕ ਵਿੱਚ ਵੱਧ ਲੈਣ-ਦੇਣ ਫਿੱਟ ਹੋ ਸਕਦੇ ਹਨ। ਜਦੋਂਕਿ ਇਸ ਨੇ ਥਰੂਪੁਟ ਵਧਾਇਆ, ਇਸ ਨੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਹਸਤਾਖਰ ਯੋਜਨਾ ਜਾਂ ਸਕ੍ਰਿਪਟ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਮੁੱਢਲੇ ਤੌਰ ਤੇ ਬਦਲਿਆ ਨਹੀਂ। ਬਿਟਕਾਇਨ ਨੇ Elliptic Curve Digital Signature Algorithm (ECDSA) ਉੱਤੇ ਨਿਰਭਰਤਾ ਜਾਰੀ ਰੱਖੀ, ਜੋ ਬਿਟਕਾਇਨ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਉਦਯੋਗ ਮਾਪਦੰਡ ਹੈ।
ਪੁਰਾਣੀ ਪ੍ਰਣਾਲੀ ਦੀਆਂ ਸੀਮਾਵਾਂ
Taproot ਤੋਂ ਪਹਿਲਾਂ, ਗੁੰਝਲਦਾਰ ਖਰਚਣ ਸ਼ਰਤਾਂ ਨੂੰ Pay-to-Script-Hash (P2SH) ਵਰਤਕੇ ਹੈਂਡਲ ਕੀਤਾ ਜਾਂਦਾ ਸੀ। ਜੇਕਰ ਇੱਕ ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਕਰਾਰ ਬਣਾਉਣਾ ਹੁੰਦਾ ਜੋ ਤਿੰਨ ਨਿੱਜੀ ਕੁੰਜੀਆਂ ਵਿੱਚੋਂ ਦੋ ਨਾਲ ਹਸਤਾਖਰ ਕਰਨ ਜਾਂ ਇੱਕ ਖਾਸ ਸਮਾਂ ਬੀਤਣ ਦੀ ਲੋੜ ਕਰਦਾ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਪੂਰੀ ਸਕ੍ਰਿਪਟ ਨੂੰ ਹੈਸ਼ ਕਰਕੇ ਬਲਾਕਚੇਨ ਉੱਤੇ ਰੱਖਣਾ ਪੈਂਦਾ।
ਜਦੋਂ ਫੰਡ ਖਰਚਣ ਦਾ ਸਮਾਂ ਆਉਂਦਾ, ਉਪਭੋਗਤਾ ਨੂੰ ਪੂਰੀ ਸਕ੍ਰਿਪਟ ਪ੍ਰਗਟ ਕਰਨੀ ਪੈਂਦੀ, ਜਿਸ ਵਿੱਚ ਅਣਪੂਰੀ ਸ਼ਰਤਾਂ ਸਮੇਤ। ਇਸ ਪ੍ਰਣਾਲੀ ਦੇ ਦੋ ਵੱਡੇ ਨੁਕਸਾਨ ਸਨ। ਪਹਿਲਾ, ਇਹ ਅਕੁਸ਼ਲ ਸੀ ਕਿਉਂਕਿ ਵੱਡੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਨੇ ਬਹੁਤ ਸਾਰਾ ਬਲਾਕ ਸਪੇਸ ਖਰਚਿਆ, ਜਿਸ ਨਾਲ ਉੱਚ ਲੈਣ-ਦੇਣ ਫੀਸ ਹੋਈ। ਦੂਜਾ, ਇਹ ਗੋਪਨੀਯਤਾ ਲਈ ਬੁਰਾ ਸੁਪਨਾ ਸੀ। ਸਮਾਰਟ ਕਰਾਰ ਦੀ ਹਰ ਸੰਭਾਵੀ ਸ਼ਰਤ ਪ੍ਰਗਟ ਕਰਕੇ, ਉਪਭੋਗਤਾ ਆਪਣੇ ਸੁਰੱਖਿਆ ਸੈੱਟਅਪ ਨੂੰ ਪੂਰੀ ਦੁਨੀਆਂ ਨੂੰ ਖੋਲ੍ਹ ਦਿੰਦੇ ਸਨ।
Taproot ਅਪਗ੍ਰੇਡ ਇਸ ਗਤੀধਾਰਾ ਨੂੰ ਮੂਲਭੂਤ ਤੌਰ ਤੇ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਹ ਉਪਭੋਕਤਾਵਾਂ ਨੂੰ ਗੁੰਝਲਦਾਰ ਸਕ੍ਰਿਪਟ ਨਾਲ ਜੁੜਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਇਸ ਦੇ ਅੰਦਰੂਨੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਪ੍ਰਗਟ ਕੀਤੇ ਜਦੋਂ ਤੱਕ ਫੰਡ ਵਾਸਤਵ ਵਿੱਚ ਖਰਚ ਨਾ ਹੋ ਜਾਣ। ਇਸ ਤੋਂ ਵੀ, ਸਿਰਫ ਉਹ ਖਾਸ ਸ਼ਰਤ ਪ੍ਰਗਟ ਹੁੰਦੀ ਹੈ ਜੋ ਫੰਡ ਖੋਲ੍ਹਣ ਲਈ ਵਰਤੀ ਗਈ, ਬਾਕੀ ਕਰਾਰ ਲੌਜਿਕ ਨੂੰ ਜਨਤਕ ਨਜ਼ਰ ਤੋਂ ਲੁਕੇਲਾ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ।
Schnorr ਹਸਤਾਖਰਾਂ ਦੀ ਸ਼ਕਤੀ
Taproot ਅਪਗ੍ਰੇਡ ਦਾ ਪਹਿਲਾ ਥੰਮ੍ਹਾ Schnorr ਹਸਤਾਖਰਾਂ (BIP 340) ਦੀ ਲਾਗੂ ਕਰਨ ਹੈ। ਇਹ ਪਬਲਿਕ ਕੁੰਜੀਆਂ ਅਤੇ ਹਸਤਾਖਰ ਉਤਪਾਦਨ ਲਈ ਪੁਰਾਣੇ ECDSA ਤੰਤਰ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਜਦੋਂਕਿ ECDSA ਸੁਰੱਖਿਅਤ ਹੈ, ਇਸ ਵਿੱਚ ਗਣਿਤੀਯ ਗੁਣ linearity ਨਹੀਂ ਹੈ। Linearity ਕਈ ਡਿਜੀਟਲ ਹਸਤਾਖਰਾਂ ਨੂੰ ਇੱਕ ਹੀ ਵੈਲਿਡ ਹਸਤਾਖਰ ਵਿੱਚ ਜੋੜਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਇਸ ਯੋਗਤਾ ਨੂੰ key aggregation ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਰਵਾਇਤੀ ਬਿਟਕਾਇਨ ਮਲਟੀ-ਹਸਤਾਖਰ ਲੈਣ-ਦੇਣ ਵਿੱਚ, ਨੈੱਟਵਰਕ ਨੂੰ ਹਰ ਵਿਅਕਤੀਗਤ ਹਸਤਾਖਰ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਅਤੇ ਬਲਾਕਚੇਨ ਉੱਤੇ ਸਟੋਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਜੇਕਰ ਤਿੰਨ ਲੋਕ ਲੈਣ-ਦੇਣ ਉੱਤੇ ਹਸਤਾਖਰ ਕਰਦੇ ਹਨ, ਤਾਂ ਤਿੰਨ ਹਸਤਾਖਰ ਅਤੇ ਤਿੰਨ ਪਬਲਿਕ ਕੁੰਜੀਆਂ ਬਲਾਕ ਵਿੱਚ ਸਪੇਸ ਲੈਂਦੀਆਂ ਹਨ। ਇਹ ਡਾਟਾ ਆਕਾਰ ਵਿੱਚ ਰੇਖੀਗਤ ਵਾਧਾ ਸੁਰੱਖਿਆ ਨੂੰ ਮਹਿੰਗਾ ਬਣਾਉਂਦਾ ਹੈ।
Schnorr ਹਸਤਾਖਰ ਇਹ ਹੱਲ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਕਈ ਪਾਰਟੀਆਂ ਨੂੰ ਆਪਣੀਆਂ ਪਬਲਿਕ ਕੁੰਜੀਆਂ ਨੂੰ ਇੱਕ ਐਗ੍ਰੀਗੇਟਿਡ ਕੁੰਜੀ ਵਿੱਚ ਜੋੜਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਉਹ ਲੈਣ-ਦੇਣ ਉੱਤੇ ਹਸਤਾਖਰ ਕਰਦੇ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਦੇ ਵਿਅਕਤੀਗਤ ਆਮ ਹਸਤਾਖਰ ਇੱਕ ਹੀ ਹਸਤਾਖਰ ਵਿੱਚ ਜੋੜੇ ਜਾਂਦੇ ਹਨ। ਬਿਟਕਾਇਨ ਨੈੱਟਵਰਕ ਲਈ, ਇਹ ਐਗ੍ਰੀਗੇਟਿਡ ਹਸਤਾਖਰ ਇੱਕ ਸਟੈਂਡਰਡ ਸਿੰਗਲ-ਉਪਭੋਗਤਾ ਹਸਤਾਖਰ ਵਾਂਗ ਲੱਗਦਾ ਹੈ। ਇਹ ਚੇਨ-ਉੱਤੇ ਸਟੋਰ ਕੀਤੇ ਡਾਟੇ ਦੀ ਮਾਤਰਾ ਨੂੰ ਕਾਫ਼ੀ ਘਟਾਉਂਦਾ ਹੈ, ਗੁੰਝਲਦਾਰ ਸੁਰੱਖਿਆ ਸੈੱਟਅਪ ਲਈ ਫੀਸ ਘਟਾਉਂਦਾ ਹੈ।
ਕੁਸ਼ਲਤਾ ਤੋਂ ਇਲਾਵਾ, Schnorr "batch validation" ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਫੁੱਲ ਨੋਡਾਂ ਨੂੰ ਪਹਿਲਾਂ ਨਾਲੋਂ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਹਸਤਾਖਰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਹਰ ਹਸਤਾਖਰ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਚੈੱਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਇੱਕ ਨੋਡ Schnorr ਹਸਤਾਖਰਾਂ ਦੇ ਬੈਚ ਨੂੰ ਇੱਕੱਠੇ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਗਣਿਤੀਯ ਕੁਸ਼ਲਤਾ ਨੈੱਟਵਰਕ ਉੱਤੇ ਗਣਨਾਤਮਕ ਲੋੜ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ, ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਆਪਣੇ ਨੋਡ ਚਲਾਉਣ ਅਤੇ ਵਿਸ਼ਵਾਸਯੋਗਤਾ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਨੂੰ ਅਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।
Merkelized Abstract Syntax Trees (MAST)
ਅਪਗ੍ਰੇਡ ਦਾ ਦੂਜਾ ਵੱਡਾ ਹਿੱਸਾ Merkelized Abstract Syntax Trees ਜਾਂ MAST ਦਾ ਏਕੀਕਰਨ ਹੈ। ਇਹ ਤਕਨੀਕ ਬਿਟਕਾਇਨ ਉੱਤੇ ਸਮਾਰਟ ਕਰਾਰਾਂ ਨੂੰ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਉਸ ਵਿੱਚ ਕ੍ਰਾਂਤੀ ਲਿਆਉਂਦੀ ਹੈ। ਕੰਪਿਊਟਰ ਵਿਗਿਆਨ ਵਿੱਚ, Merkle ਟ੍ਰੀ ਇੱਕ ਡਾਟਾ ਢਾਂਚਾ ਹੈ ਜੋ ਪੂਰੇ ਡਾਟਾ ਸੈੱਟ ਤੋਂ ਬਿਨਾਂ ਵੱਡੇ ਡਾਟਾ ਸੈੱਟਾਂ ਦੀ ਕੁਸ਼ਲ ਪ੍ਰਮਾਣਿਤੀ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। MAST ਇਸ ਸੰਕਲਪ ਨੂੰ ਬਿਟਕਾਇਨ ਸਕ੍ਰਿਪਟਾਂ ਉੱਤੇ ਲਾਗੂ ਕਰਦਾ ਹੈ।
ਪੁਰਾਣੇ P2SH ਪ੍ਰਣਾਲੀ ਅਧੀਨ, ਸਮਾਰਟ ਕਰਾਰ ਇੱਕ ਇਕਲੀ ਰੇਖੀ ਸਕ੍ਰਿਪਟ ਸੀ। ਜੇਕਰ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਕਈ ਖਰਚਣ ਸ਼ਰਤਾਂ (ਸ਼ਾਖਾਵਾਂ) ਹੁੰਦੀਆਂ, ਤਾਂ ਪੂਰੀ ਸਕ੍ਰਿਪਟ ਨੂੰ ਪ੍ਰੋਸੈਸ ਅਤੇ ਪ੍ਰਗਟ ਕਰਨਾ ਪੈਂਦਾ। MAST ਇਹ ਸ਼ਰਤਾਂ ਨੂੰ Merkle ਟ੍ਰੀ ਉੱਤੇ ਵੱਖਰੇ ਪੱਤੇ ਵਿੱਚ ਵੰਡ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਉਪਭੋਗਤਾ ਫੰਡ ਖਰਚਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸਿਰਫ ਉਹ ਖਾਸ ਪੱਤਾ (ਸ਼ਰਤ) ਅਤੇ "Merkle proof" ਪ੍ਰਦਾਨ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਜੋ ਉਸ ਪੱਤੇ ਨੂੰ ਟ੍ਰੀ ਦੇ ਰੂਟ ਨਾਲ ਜੋੜਦੀ ਹੈ।
ਚੋਣਵੀਂ ਪ੍ਰਗਟੀ ਰਾਹੀਂ ਕੁਸ਼ਲਤਾ
MAST ਦਾ ਮੁੱਖ ਲਾਭ ਕੁਸ਼ਲਤਾ ਹੈ। ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਗੁੰਝਲਦਾਰ ਵਿਰਾਸਤ ਕਰਾਰ ਜਿਸ ਵਿੱਚ ਫੰਡਾਂ ਤੱਕ ਪਹੁੰਚਣ ਦੇ ਦਸ ਵੱਖਰੇ ਤਰੀਕੇ ਹਨ, ਵੱਖ-ਵੱਖ ਪਰਿਵਾਰਕ ਮੈਂਬਰਾਂ ਅਤੇ ਸਮੇਂ ਦੀ ਬਿਲੰਬ ਨਾਲ। ਪੁਰਾਣੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ, ਸਾਰੀਆਂ ਦਸ ਸ਼ਰਤਾਂ ਬਲਾਕ ਸਪੇਸ ਭਰਦੀਆਂ। MAST ਨਾਲ, ਜੇਕਰ ਮੁੱਖ ਲਾਭਪਾਤਰੀ ਸਭ ਤੋਂ ਸਾਧਾਰਨ ਸ਼ਰਤ ਨਾਲ ਫੰਡਾਂ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਤਾਂ ਸਿਰਫ ਉਹ ਇੱਕ ਸ਼ਰਤ ਪ੍ਰਗਟ ਅਤੇ ਚੇਨ-ਉੱਤੇ ਸਟੋਰ ਹੁੰਦੀ ਹੈ।
ਅਣਕੀਤਰੀਕ੍ਰਿਤ ਸ਼ਾਖਾਵਾਂ ਹੈਸ਼ ਕੀਤੀਆਂ ਅਤੇ ਲੁਕੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸੌ ਸੰਭਾਵੀ ਖਰਚਣ ਸ਼ਰਤਾਂ ਵਾਲਾ ਲੈਣ-ਦੇਣ ਇੱਕ ਸ਼ਰਤ ਵਾਲੇ ਲੈਣ-ਦੇਣ ਜਿੰਨਾ ਛੋਟਾ ਅਤੇ ਸਸਤਾ ਹੋ ਸਕਦਾ ਹੈ। ਕਰਾਰ ਗੁੰਝਲਦਾਰਤਾ ਨੂੰ ਲੈਣ-ਦੇਣ ਲਾਗਤ ਤੋਂ ਵੱਖ ਕਰਕੇ ਉੱਨਤ ਸੁਰੱਖਿਆ ਉਪਾਵਾਂ ਵਰਤਣ ਲਈ ਵਿੱਤੀ ਜੁਰਮਾਨਾ ਹਟਾਉਂਦਾ ਹੈ।
ਲੁਕੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਤੋਂ ਗੋਪਨੀਯਤਾ ਲਾਭ
MAST ਡੂੰਘੀ ਗੋਪਨੀਯਤਾ ਵਾਧੇ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ ਅਣਕੀਤਰੀਕ੍ਰਿਤ ਸ਼ਾਖਾਵਾਂ ਕਦੇ ਪ੍ਰਗਟ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਬਾਹਰੀ ਉਪਭੋਗਤਾ ਉਪਭੋਗਤਾ ਦੇ ਵਾਲਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਪੂਰੀ ਵੇਰਵੇ ਨਹੀਂ ਜਾਣ ਸਕਦੇ। ਬਲਾਕਚੇਨ ਵੇਖਣ ਵਾਲਾ ਉਪਭੋਗਤਾ ਸਿਰਫ ਉਹੀ ਸ਼ਰਤ ਵੇਖਦਾ ਹੈ ਜੋ ਪੂਰੀ ਹੋਈ, ਨਾ ਕਿ ਰਿਜ਼ਰਵ ਵਿੱਚ ਰੱਖੀਆਂ।
ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਉਪਭੋਕਤਾ ਦੇ ਵਾਲਟ ਨੂੰ ਉਸ ਦੇ ਹਾਰਡਵੇਅਰ ਵਾਲਟ ਨਾਲ ਤੁਰੰਤ ਜਾਂ ਭਰੋਸੇਯੋਗ ਤੀਜੀ ਪਾਰਟੀ ਨਾਲ ਇੱਕ ਸਾਲ ਦੀ ਬਿਲੰਬ ਤੋਂ ਬਾਅਦ ਖੋਲ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਉਪਭੋਗਤਾ ਆਮ ਤੌਰ ਤੇ ਹਾਰਡਵੇਅਰ ਵਾਲਟ ਨਾਲ ਖਰਚਦਾ ਹੈ, ਤਾਂ ਤੀਜੀ ਪਾਰਟੀ ਬੈਕਅਪ ਸ਼ਰਤ ਦੀ ਹੋਂਦ ਜਨਤਕ ਨੂੰ ਕਦੇ ਪ੍ਰਗਟ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਚੋਣਵੀਂ ਪ੍ਰਗਟੀ ਚੇਨ ਵਿਸ਼ਲੇਸ਼ਣ ਫਰਮਾਂ ਲਈ ਵਾਲਟਸ ਨੂੰ ਫਿੰਗਰਪ੍ਰਿੰਟ ਕਰਨ ਜਾਂ ਉਪਭੋਕਤਾ ਦੇ ਸੁਰੱਖਿਆ ਸੈੱਟਅਪ ਦੀ ਗੁੰਝਲਦਾਰਤਾ ਨਿਰਧਾਰਤ ਕਰਨ ਨੂੰ ਬਹੁਤ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੀ ਹੈ।
Pay-to-Taproot (P2TR) ਅਤੇ Key Path Spending
Taproot Schnorr ਹਸਤਾਖਰਾਂ ਅਤੇ MAST ਨੂੰ Pay-to-Taproot (P2TR) ਨਾਮਕ ਨਵੇਂ ਲੈਣ-ਦੇਣ ਆਊਟਪੁਟ ਵਰਗ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ, ਜੋ BIP 341 ਵਿੱਚ ਵਰਣਿਤ ਹੈ। ਇਹ ਢਾਂਚਾ ਬਿਟਕਾਇਨ ਆਊਟਪੁਟ ਨੂੰ ਦੋ ਵੱਖਰੇ ਤਰੀਕਿਆਂ ਨਾਲ ਖਰਚਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ: "key path" ਅਤੇ "script path।" ਇਹ ਦੁਹਰੀ ਯੋਗਤਾ ਹੀ Taproot ਲੈਣ-ਦੇਣਾਂ ਨੂੰ ਬਲਾਕਚੇਨ ਉੱਤੇ ਏਕਸਾਰ ਬਣਾਉਂਦੀ ਹੈ।
Key path Schnorr ਦੀ key aggregation ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਸਮਾਰਟ ਕਰਾਰ ਵਿੱਚ ਸਾਰੀਆਂ ਪਾਰਟੀਆਂ ਕੋਈ ਕਾਰਵਾਈ ਉੱਤੇ ਸਹਿਮਤ ਹਨ, ਤਾਂ ਉਹ ਸਹਿਯੋਗ ਨਾਲ ਇੱਕ ਹੀ ਹਸਤਾਖਰ ਬਣਾ ਕੇ ਫੰਡ ਖਰਚ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਸਹਿਯੋਗੀ ਬੰਦ ਕਰਨ ਦਾ ਸੀਨੇਰੀਓ ਹੈ। ਨੈੱਟਵਰਕ ਲਈ ਇਹ ਇੱਕ ਸਾਧਾਰਨ ਵਿਅਕਤੀ-ਤੋਂ-ਵਿਅਕਤੀ ਭੁਗਤਾਨ ਵਾਂਗ ਲੱਗਦਾ ਹੈ। ਕੋਈ ਅੰਤਰੀਵ ਰੂਪ ਵਿੱਚ ਸਕ੍ਰਿਪਟ ਪ੍ਰਗਟ ਨਹੀਂ ਹੁੰਦੀ ਕਿਉਂਕਿ ਖਰਚਣ ਅਧਿਕਾਰ ਚੇਨ-ਬਾਹਰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਰਾਹੀਂ ਹੈਂਡਲ ਕੀਤਾ ਗਿਆ।
ਜੇਕਰ ਪਾਰਟੀਆਂ ਸਹਿਮਤ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ, ਜਾਂ ਕੋਈ ਖਾਸ ਗੁੰਝਲਦਾਰ ਸ਼ਰਤ ਪੂਰੀ ਕਰਨੀ ਹੈ, ਤਾਂ ਵਾਲਟ script path ਉੱਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ। ਇੱਥੇ MAST ਆਉਂਦਾ ਹੈ। ਵਾਲਟ ਫੰਡ ਖੋਲ੍ਹਣ ਲਈ ਚਾਹੀਦੀ Merkle ਟ੍ਰੀ ਦੀ ਖਾਸ ਸ਼ਾਖਾ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ। P2TR ਦੀ ਬੁੱਧੀਮਾਨੀ ਇਹ ਹੈ ਕਿ ਬਲਾਕਚੇਨ ਉੱਤੇ ਪਬਲਿਕ ਕੁੰਜੀ ਆਸਲ ਵਿੱਚ ਉਪਭੋਗਤਾ ਦੀ ਪਬਲਿਕ ਕੁੰਜੀ ਅਤੇ MAST ਦੇ ਰੂਟ ਦਾ ਸੰਯੋਜਨ ਹੈ।
ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ P2TR ਆਊਟਪੁਟ ਖਰਚੇ ਤੱਕ ਇੱਕੋ ਜਿਹਾ ਲੱਗਦਾ ਹੈ। ਇੱਕ ਉਪਭੋਗਤਾ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ P2TR ਪਤਾ ਇੱਕ ਸਾਧਾਰਨ ਸਿੰਗਲ-ਸਿਗ ਵਾਲਟ ਹੈ, ਮਲਟੀ-ਸਿਗ ਸੈੱਟਅਪ ਹੈ, ਜਾਂ ਗੁੰਝਲਦਾਰ ਸਮਾਰਟ ਕਰਾਰ। ਜੇਕਰ ਉਪਭੋਕਤਾ key path ਰਾਹੀਂ ਖਰਚਦਾ ਹੈ, ਤਾਂ script path ਦੀ ਹੋਂਦ ਗਣਿਤੀ ਤੌਰ ਤੇ ਹਮੇਸ਼ਾ ਲੁਕੀ ਰਹਿੰਦੀ ਹੈ। ਇਹ ਸੰਕਲਪਾ, "cooperative close" ਵਜੋਂ ਜਾਣੀ ਜਾਂਦੀ ਹੈ, ਫੀਸ ਬਚਾਉਣ ਅਤੇ ਗੋਪਨੀਯਤਾ ਬਣਾਈ ਰੱਖਣ ਲਈ ਚੇਨ-ਬਾਹਰ ਸਹਿਮਤੀ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ।
| ਵਿਸ਼ੇਸ਼ਤਾ | ਪੁਰਾਣਾ (P2SH/ECDSA) | Taproot (P2TR/Schnorr) |
|---|---|---|
| ਹਸਤਾਖਰ ਐਲਗੋਰਿਦਮ | ECDSA | Schnorr |
| ਗੋਪਨੀਯਤਾ | ਪੂਰੀ ਸਕ੍ਰਿਪਟ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ | ਸਿਰਫ ਕੀਤੀ ਗਈ ਸ਼ਾਖਾ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ |
| ਮਲਟੀ-ਸਿਗ ਡਾਟਾ | ਹਰ ਸਾਈਨਰ ਲਈ ਇੱਕ ਹਸਤਾਖਰ | ਇੱਕ ਐਗ੍ਰੀਗੇਟਿਡ ਹਸਤਾਖਰ |
| ਕੁਸ਼ਲਤਾ | ਗੁੰਝਲਦਾਰਤਾ ਨਾਲ ਲਾਗਤ ਵਧਦੀ ਹੈ | key path ਲਈ ਸਥਿਰ ਲਾਗਤ |
| ਬਦਲਣਯੋਗਤਾ | ਵੱਖਰੇ ਵਾਲਟ ਫਿੰਗਰਪ੍ਰਿੰਟ | ਏਕਸਾਰ ਲੈਣ-ਦੇਣ ਰੂਪ |
ਬਿਟਕਾਇਨ ਸਮਾਰਟ ਕਰਾਰਾਂ ਦਾ ਵਿਕਾਸ
ਜਦੋਂਕਿ ਬਿਟਕਾਇਨ Ethereum ਵਰਗਾ Turing-complete ਸਮਾਰਟ ਕਰਾਰ ਪਲੇਟਫਾਰਮ ਨਹੀਂ ਹੈ, ਇਸ ਕੋਲ ਗੰਭੀਰ ਵਿੱਤੀ ਲੌਜਿਕ ਨੂੰ ਹੈਂਡਲ ਕਰਨ ਯੋਗ ਮਜ਼ਬੂਤ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾ ਹੈ। Taproot ਇਸ ਯੋਗਤਾ ਨੂੰ ਕਾਫ਼ੀ ਵਧਾਉਂਦਾ ਹੈ। ਗੁੰਝਲਦਾਰ ਸਕ੍ਰਿਪਟਾਂ ਲਈ ਲਾਗਤ ਜੁਰਮਾਨਾ ਹਟਾ ਕੇ, ਇਹ ਵਿਕਾਸਕਾਰੀਆਂ ਨੂੰ ਬਿਟਕਾਇਨ ਬੇਸ ਲੇਅਰ ਉੱਤੇ ਵੱਧ ਗੁੰਝਲਦਾਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਣ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ।
ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਬਿਟਕਾਇਨ ਹੋਰ ਚੇਨਾਂ ਦੀ ਕਾਰਵਾਈ ਨੂੰ ਕਾਪੀ ਕਰ ਰਿਹਾ ਹੈ। ਬਲਕਿ ਇਹ ਗਣਨਾ ਨਾਲੋਂ ਪ੍ਰਮਾਣਿਤੀ ਉੱਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰਦਾ ਹੈ। ਬਿਟਕਾਇਨ ਸਮਾਰਟ ਕਰਾਰ ਮੁੱਢਲੇ ਤੌਰ ਤੇ ਅਧਿਕਾਰ ਸ਼ਰਤਾਂ ਬਾਰੇ ਹਨ: ਕੌਣ ਪੈਸੇ ਖਰਚ ਸਕਦਾ ਹੈ ਅਤੇ ਕਦੋਂ। Taproot ਇਹਨਾਂ ਅਧਿਕਾਰ ਸ਼ਰਤਾਂ ਨੂੰ ਚੇਨ-ਬਾਹਰ ਇਰਾਦਤਨ ਗੁੰਝਲਦਾਰ ਬਣਾਉਂਦਾ ਹੈ, ਜਦੋਂਕਿ ਚੇਨ-ਉੱਤੇ ਸਾਧਾਰਨ ਅਤੇ ਸੰਖੇਪ ਰੱਖਦਾ ਹੈ।
Tapscript ਅਤੇ ਭਵਿੱਖੀ ਅਪਗ੍ਰੇਡ
ਇਹਨਾਂ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਮਰਥਨ ਦੇਣ ਲਈ, ਅਪਗ੍ਰੇਡ ਨੇ Tapscript (BIP 342) ਪੇਸ਼ ਕੀਤਾ, ਜੋ ਬਿਟਕਾਇਨ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾ ਦਾ ਅਪਡੇਟਿਡ ਵਰਜਨ ਹੈ। Tapscript ਹਸਤਾਖਰ ਪ੍ਰਮਾਣਿਤੀ ਨੂੰ ਬਦਲਦਾ ਹੈ ਅਤੇ ਕੁਝ "opcodes" (ਆਪਰੇਸ਼ਨ ਕੋਡ) ਨੂੰ ਵਾਪਸ ਪੇਸ਼ ਕਰਦਾ ਜਾਂ ਬਦਲਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਵੱਧ ਲਚਕੀਲੇ ਹੋਣ।
Tapscript ਵਿੱਚ ਮੁੱਖ ਬਦਲਾਅ ਵਿੱਚ witness data ਉੱਤੇ ਸਖ਼ਤ ਆਕਾਰ ਸੀਮਾ ਹਟਾਉਣਾ ਸ਼ਾਮਲ ਹੈ। ਪਹਿਲਾਂ, ਪ੍ਰੋਸੈਸ ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਉੱਤੇ ਹਾਰਡ ਕੈਪ ਸੀ। Tapscript ਇਹਨਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਢਿੱਲਾ ਕਰਦਾ ਹੈ, ਬਲਾਕ ਵਜ਼ਨ ਸੀਮਾਵਾਂ ਵਿੱਚ ਫਿੱਟ ਹੋਣ ਤੇ ਵੱਡੀਆਂ ਅਤੇ ਵੱਧ ਗੁੰਝਲਦਾਰ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।
ਇਸ ਤੋਂ ਵਿਸ਼ੇਸ਼ ਤੌਰ ਤੇ, Tapscript ਭਵਿੱਖੀ ਅਪਗ੍ਰੇਡਯੋਗਤਾ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਹ ਅਣਪਛਾਤੇ opcodes ਨੂੰ ਹੈਂਡਲ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨੂੰ ਰੀਡਿਫਾਇਨ ਕਰਦਾ ਹੈ। ਪੁਰਾਣੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ, ਨਵਾਂ opcode ਪੇਸ਼ ਕਰਨਾ ਅਕਸਰ ਗੁੰਝਲਦਾਰ ਅਪਗ੍ਰੇਡ ਪ੍ਰਕਿਰਿਆ ਦੀ ਲੋੜ ਕਰਦਾ ਸੀ। Tapscript ਨਾਲ, ਅਣਪਛਾਤੇ opcodes ਆਪਣੇ ਆਪ ਵੈਲਿਡ (no-ops) ਵਜੋਂ ਟ੍ਰੀਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਨਰਮ ਫੋਰਕ ਰਾਹੀਂ ਬਾਅਦ ਵਿੱਚ ਨਵੀਂ ਕਾਰਵਾਈ ਪੇਸ਼ ਕਰਨ ਨੂੰ ਬਹੁਤ ਅਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਬਿਨਾਂ ਨੈੱਟਵਰਕ ਵਿਘਨ ਪਾਏ। ਇਹ ਅੱਗੇ ਵਧਣ ਵਾਲਾ ਵਿਚਾਰ ਬਿਟਕਾਇਨ ਨੂੰ ਨਵੀਆਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਨਵੀਨਤਾਵਾਂ ਅਨੁਕੂਲ ਹੋਣ ਵਿੱਚ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ।
Layer-2 ਹੱਲਾਂ ਉੱਤੇ ਪ੍ਰਭਾਵ
Taproot ਦੇ ਨਤੀਜੇ ਬੇਸ ਲੇਅਰ ਤੋਂ ਬਹੁਤ ਅੱਗੇ ਵਧਦੇ ਹਨ, Lightning Network ਵਰਗੇ Layer-2 ਸਕੇਲਿੰਗ ਹੱਲਾਂ ਨੂੰ ਕਾਫ਼ੀ ਲਾਭ ਪਹੁੰਚਾਉਂਦੇ ਹਨ। ਹੁਣੇ, ਇੱਕ Lightning ਚੈਨਲ ਖੋਲ੍ਹਣ ਜਾਂ ਬੰਦ ਕਰਨ ਵਿੱਚ 2-of-2 ਮਲਟੀ-ਹਸਤਾਖਰ ਲੈਣ-ਦੇਣ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਪੁਰਾਣੀ ਚੇਨ ਉੱਤੇ, ਇਹ ਲੈਣ-ਦੇਣ ਵੱਖਰੇ ਅਤੇ ਅਸਾਨੀ ਨਾਲ ਪਛਾਣੇ ਜਾਂਦੇ ਹਨ।
Taproot ਨਾਲ, ਇੱਕ Lightning ਚੈਨਲ ਖੋਲ੍ਹਣ ਜਾਂ ਬੰਦ ਕਰਨ ਵਿੱਚ key path ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ Lightning ਲੈਣ-ਦੇਣ ਇੱਕ ਸਟੈਂਡਰਡ ਉਪਭੋਗਤਾ ਭੁਗਤਾਨ ਵਾਂਗ ਲੱਗਦਾ ਹੈ। ਇਹ Lightning Network ਉਪਭੋਕਤਾਵਾਂ ਦੀ ਗੋਪਨੀਯਤਾ ਵਧਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਚੇਨ-ਉੱਤੇ ਭੁਗਤਾਨਾਂ ਅਤੇ ਚੈਨਲ ਪ੍ਰਬੰਧਨ ਕਾਰਵਾਈਆਂ ਵਿਚਕਾਰ ਅੰਤਰ ਪਛਾਣਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇਸ ਤੋਂ ਇਲਾਵਾ, Taproot Point Time Locked Contracts (PTLCs) ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ ਜੋ Lightning ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ Hashed Time Locked Contracts (HTLCs) ਨੂੰ ਬਦਲਣਗੇ। PTLCs Schnorr ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਭੁਗਤਾਨ ਰੂਟ boyunca ਗੋਪਨੀਯਤਾ ਵਧਾਉਂਦੇ ਹਨ। HTLC ਵਿੱਚ, ਪੂਰੇ ਰੂਟ ਉੱਤੇ ਇੱਕੋ ਹੈਸ਼ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਨੋਡਾਂ ਨੂੰ ਭੁਗਤਾਨਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਸੰਭਾਵਨਾ ਦਿੰਦਾ ਹੈ। PTLCs ਹਰ ਹੌਪ ਉੱਤੇ ਰੈਂਡਮਾਈਜ਼ਡ ਸਕੇਲਰ ਵਰਤਦੇ ਹਨ, ਇਹ ਲਿੰਕ ਤੋੜਦੇ ਹਨ ਅਤੇ ਭੁਗਤਾਨ ਰੂਟ ਨੂੰ ਵਿਚਕਾਰੀਆਂ ਲਈ ਗਣਿਤੀ ਤੌਰ ਤੇ ਅਸਪਸ਼ਟ ਬਣਾਉਂਦੇ ਹਨ।
ਬਿਟਕਾਇਨ ਸੱਤਾ ਅਤੇ ਸਰਗਰਮੀਕਰਨ
Taproot ਨੂੰ ਸਰਗਰਮ ਕਰਨ ਦਾ ਰਾਹ ਬਿਟਕਾਇਨ ਸੱਤਾ ਦੀ ਵਿਲੱਖਣ ਪ੍ਰਕਿਰਤੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਕੇਂਦਰੀਕ੍ਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਜਿੱਥੇ ਆਗੂ ਅਪਗ੍ਰੇਡ ਡਿਕਟੇਟ ਕਰਦੇ ਹਨ, ਬਿਟਕਾਇਨ ਵਿਤਰਿਤ ਹਿੱਸੇਦਾਰਾਂ ਵਿੱਚ ਸਹਿਮਤੀ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਮਾਈਨਰ, ਵਿਕਾਸਕਾਰ ਅਤੇ ਨੋਡ ਆਪਰੇਟਰ ਸ਼ਾਮਲ ਹਨ। Taproot ਲਈ ਵਰਤੀ ਗਈ ਸਰਗਰਮੀਕਰਨ ਪ੍ਰਕਿਰਿਆ "Speedy Trial" ਵਜੋਂ ਜਾਣੀ ਜਾਂਦੀ ਸੀ।
ਇਹ ਤੰਤਰ ਮਾਈਨਰਾਂ ਨੂੰ ਤਿੰਨ ਮਹੀਨੇ ਦੀ ਖਿੜਕੀ ਵਿੱਚ ਆਪਣੇ ਮਾਈਨ ਕੀਤੇ ਬਲਾਕਾਂ ਵਿੱਚ ਅਪਗ੍ਰੇਡ ਲਈ ਸਮਰਥਨ ਦਰਸਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਸੀ। ਸਰਗਰਮੀਕਰਨ ਲਈ ਥਰੈਸ਼ਹੋਲਡ ਇੱਕ ਔਸਤ ਯੁੱਗ ਵਿੱਚ 90% ਬਲਾਕਾਂ ਉੱਤੇ ਸੈੱਟ ਕੀਤੀ ਗਈ ਸੀ। ਇਹ ਉੱਚ ਮਾਪਦੰਡ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਅਪਗ੍ਰੇਡ ਸਿਰਫ਼ ਭਾਰੀ ਸਹਿਮਤੀ ਹੋਣ ਤੇ ਅੱਗੇ ਵਧੇ, ਨੈੱਟਵਰਕ ਵੰਡ ਜਾਂ ਵਿਵਾਦੀ ਹਾਰਡ ਫੋਰਕ ਰੋਕਦੇ ਹੋਏ।
ਨਵੰਬਰ 2021 ਵਿੱਚ ਸਫਲ ਸਰਗਰਮੀਕਰਨ ਨੇ ਸਾਬਤ ਕੀਤਾ ਕਿ ਬਿਟਕਾਇਨ ਆਪਣੇ ਵਿਸ਼ਾਲ ਆਕਾਰ ਅਤੇ ਵਿਤਰਿਤ ਪ੍ਰਕਿਰਤੀ ਦੇ ਬਾਵਜੂਦ ਗੁੰਝਲਦਾਰ ਅਪਗ੍ਰੇਡਾਂ ਨੂੰ ਏਕਤਾ ਵਿੱਚ ਕੋਆਰਡੀਨੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਨੇ "ਸਾਫਟ ਫੋਰਕਾਂ" ਲਈ ਸੱਭਿਆਚਾਰਕ ਤਰਜੀਹ ਨੂੰ ਉਜਾਗਰ ਕੀਤਾ—ਪਿਛਲੇ ਅਨੁਕੂਲ ਅਪਗ੍ਰੇਡ ਜੋ ਉਪਭੋਕਤਾਵਾਂ ਨੂੰ ਤੁਰੰਤ ਸੌਫਟਵੇਅਰ ਅਪਡੇਟ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰਦੇ। Taproot ਨੋਡ ਪੁਰਾਣੇ ਨੋਡਾਂ ਨਾਲ ਸੰਚਾਰ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹਨ, ਅਪਗ੍ਰੇਡ ਨਾ ਕਰਨ ਲਈ ਕਿਸੇ ਨੂੰ ਨੈੱਟਵਰਕ ਤੋਂ ਨਿਕਾਲਿਆ ਨਹੀਂ ਜਾਂਦਾ।
ਅਣਚਾਹੇ ਨਤੀਜੇ: Ordinals ਦਾ ਉਭਾਰ
Taproot ਅਪਗ੍ਰੇਡ ਦਾ ਇੱਕ ਸਭ ਤੋਂ ਹੈਰਾਨੀ ਵਾਲਾ ਨਤੀਜਾ ਬਿਟਕਾਇਨ Ordinals ਦਾ ਉਭਾਰ ਸੀ। ਜਦੋਂਕਿ Taproot ਨੂੰ ਵਿੱਤੀ ਸਮਾਰਟ ਕਰਾਰਾਂ ਵਧਾਉਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਸੀ, Tapscript ਰਾਹੀਂ witness ਫੀਲਡ ਵਿੱਚ ਡਾਟਾ ਸੀਮਾਵਾਂ ਨੂੰ ਢਿੱਲਾ ਕਰਨ ਨੇ ਬਲਾਕਚੇਨ ਉੱਤੇ ਇਰਾਦੇ-ਬਿਨਾਂ ਡਾਟਾ ਸਟੋਰ ਕਰਨ ਦਾ ਦਰਵਾਜ਼ਾ ਖੋਲ੍ਹ ਦਿੱਤਾ।
Ordinals ਉਪਭੋਕਤਾਵਾਂ ਨੂੰ ਡਾਟਾ—ਜਿਵੇਂ ਤਸਵੀਰਾਂ, ਟੈਕਸਟ ਜਾਂ ਕੋਡ—ਨੂੰ ਸਿੱਧੇ ਇੱਕਲੇ satoshis (ਬਿਟਕਾਇਨ ਦੀ ਸਭ ਤੋਂ ਛੋਟੀ ਇਕਾਈ) ਉੱਤੇ ਇਨਸਕ੍ਰਾਈਬ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ। ਕਿਉਂਕਿ Taproot ਨੇ witness data ਲਈ ਆਕਾਰ ਸੀਮਾ ਹਟਾ ਦਿੱਤੀ, ਉਪਭੋਕਤਾ ਅਚਾਨਕ ਇੱਕ ਬਲਾਕ ਵਿੱਚ 4MB ਡਾਟੇ ਨਾਲ ਲੈਣ-ਦੇਣ ਕਰ ਸਕਦੇ ਸਨ, ਜੇਕਰ ਉਹ ਲੋੜੀਂਦੀ ਫੀਸ ਅਦਾ ਕਰਦੇ। ਇਸ ਨੇ ਬਿਟਕਾਇਨ ਉੱਤੇ ਸਿੱਧੇ "ਡਿਜੀਟਲ ਆਰਟੀਫੈਕਟਸ" ਜਾਂ NFTs ਲਈ ਬਜ਼ਾਰ ਨੂੰ ਜਨਮ ਦਿੱਤਾ।
ਇਸ ਵਿਕਾਸ ਨੇ ਕਮਿਊਨਿਟੀ ਵਿੱਚ ਤੀਬਰ ਬਹਿਸ ਛੇੜ ਦਿੱਤੀ। ਸ਼ੁੱਧਤਾਵਾਦੀ ਇਹ ਦਲੀਲ ਦਿੰਦੇ ਹਨ ਕਿ ਇਹ ਬਲਾਕਚੇਨ ਨੂੰ ਗੈਰ-ਵਿੱਤੀ ਡਾਟੇ ਨਾਲ "ਭਾਰੀ" ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਫੁੱਲ ਨੋਡ ਚਲਾਉਣ ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾ ਸਕਦਾ ਹੈ। ਸਮਰਥਕ ਦਲੀਲ ਦਿੰਦੇ ਹਨ ਕਿ Ordinals ਇਨਸਕ੍ਰਿਪਸ਼ਨਾਂ ਵੱਲੋਂ ਅਦਾ ਕੀਤੀ ਉੱਚ ਫੀਸ ਬਲਾਕ ਸਬਸਿਡੀ ਘਟਣ ਤੇ ਨੈੱਟਵਰਕ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦੀ ਹੈ। ਸਥਿਤੀ ਬਾਰੇ ਬਾਵਾਂਜੂਦ, Ordinals ਨੇ Taproot ਆਰਕੀਟੈਕਚਰ ਦੀ ਲਚਕ ਅਤੇ ਓਪਨ-ਸੋਰਸ ਪ੍ਰੋਟੋਕੋਲਾਂ ਨੂੰ ਜੰਗਲ ਵਿੱਚ ਛੱਡਣ ਤੋਂ ਬਾਅਦ ਉਹਨਾਂ ਦੀ ਅਨਪੇਸ਼ ਕੀਤੀ ਵਰਤੋਂ ਨੂੰ ਦਰਸਾਇਆ।
Covenants ਅਤੇ OP_CAT ਦੀ ਵਾਪਸੀ
Taproot ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤੀ ਲਚਕ ਨੇ ਬਿਟਕਾਇਨ ਦੀਆਂ ਸਕ੍ਰਿਪਟਿੰਗ ਯੋਗਤਾਵਾਂ ਨੂੰ ਹੋਰ ਵਧਾਉਣ ਬਾਰੇ ਚਰਚਾਵਾਂ ਨੂੰ ਨਵੀਂ ਜ਼ਿੰਦਗੀ ਦਿੱਤੀ ਹੈ। ਹੁਣੇ ਚੱਲ ਰਹੀਆਂ ਖੋਜਾਂ ਦਾ ਮੁੱਖ ਵਿਸ਼ਾ "covenants" ਹੈ—ਸਕ੍ਰਿਪਟ ਜੋ ਫੰਡਾਂ ਨੂੰ ਬਾਅਦ ਖਰਚੇ ਤੋਂ ਬਾਅਦ ਕਿੱਥੇ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ ਉੱਤੇ ਪਾਬੰਦੀ ਲਗਾਉਂਦੀਆਂ ਹਨ। ਹੁਣੇ, ਬਿਟਕਾਇਨ ਸਕ੍ਰਿਪਟ ਸਿਰਫ ਅਧਿਕਾਰ (ਕੌਣ ਖਰਚ ਸਕਦਾ ਹੈ) ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀ ਹੈ, ਨਾ ਕਿ ਗੰਤਵਯ (ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ) ਨੂੰ।
Covenants ਅਤੇ ਵੱਧ ਉੱਨਤ ਸਾਈਡਚੇਨ ਪੁਲਾਂ ਨੂੰ ਸੰਭਵ ਬਣਾਉਣ ਲਈ, ਵਿਕਾਸਕਾਰ OP_CAT opcode ਨੂੰ ਵਾਪਸ ਪੇਸ਼ ਕਰਨ ਬਾਰੇ ਚਰਚਾ ਕਰ ਰਹੇ ਹਨ। OP_CAT ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਦੋ ਡਾਟਾ ਟੁਕੜਿਆਂ ਨੂੰ ਜੋੜਨ (ਕੈਟਨੇਟ ਕਰਨ) ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇਹ ਬਿਟਕਾਇਨ ਦੇ ਸ਼ੁਰੂਆਤੀ ਦਿਨਾਂ ਵਿੱਚ ਮੈਮੋਰੀ ਵਰਤੋਂ ਦੀਆਂ ਚਿੰਤਾਵਾਂ ਕਾਰਨ ਹਟਾਇਆ ਗਿਆ ਸੀ, ਪਰ Tapscript ਦੇ ਆਧੁਨਿਕ ਸੁਰੱਖਿਆ ਨਾਲ ਇਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਾਪਸ ਲਿਆਂਦਾ ਜਾ ਸਕਦਾ ਹੈ।
ਜੇਕਰ ਸਰਗਰਮ ਕੀਤਾ ਗਿਆ, ਤਾਂ OP_CAT Taproot ਨਾਲ ਮਿਲ ਕੇ ਹੋਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਮਾਰਟ ਕਰਾਰਾਂ ਨੂੰ ਸੰਭਵ ਬਣਾਏਗਾ, ਜਿਵੇਂ ਵਿਤਰਿਤ ਵਾਲਟ ਜੋ ਫੰਡਾਂ ਨੂੰ ਨਵੇਂ ਪਤੇ ਤੇ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਇੰਤਜ਼ਾਰ ਅਵਧੀ ਨੂੰ ਜ਼ਬਰਦਸਤੀ ਕਰਦੇ ਹਨ, ਅਸਲ ਵਿੱਚ ਨਿੱਜੀ ਕੁੰਜੀਆਂ ਚੋਰੀ ਹੋਣ ਤੇ ਵੀ ਚੋਰੀ ਨੂੰ ਨਾਕਾਮ ਕਰਦੇ ਹਨ। ਇਹ ਬਿਟਕਾਇਨ ਸਕ੍ਰਿਪਟਿੰਗ ਦੇ ਜਾਰੀ ਵਿਕਾਸ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਜੋ Taproot ਵੱਲੋਂ ਰੱਖੀ ਨੀਂਹ ਉੱਤੇ ਬਣਦਾ ਹੈ।
ਨਿਗਮਨ
Taproot ਅਤੇ MAST ਦਾ ਏਕੀਕਰਨ ਬਿਟਕਾਇਨ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਪੱਕਵਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਗੁੰਝਲਦਾਰ ਪ੍ਰਮਾਣਿਤੀ ਲੌਜਿਕ ਨੂੰ ਚੇਨ-ਬਾਹਰ ਲੈ ਜਾ ਕੇ ਅਤੇ ਉੱਨਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਬਿਟਕਾਇਨ ਨੇ ਆਪਣੀਆਂ ਮੁੱਢਲੀਆਂ ਕੀਮਤਾਂ ਸੁਰੱਖਿਆ ਅਤੇ ਵਿਤਰਿਤਤਾ ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਆਪਣੀ ਕਾਰਵਾਈ ਨੂੰ ਸਕੇਲ ਕੀਤਾ ਹੈ। ਅਪਗ੍ਰੇਡ ਨੇ ਗੋਪਨੀਯਤਾ ਅਤੇ ਕਾਰਵਾਈ ਵਿਚਕਾਰ ਤਣਾਅ ਨੂੰ ਹੱਲ ਕੀਤਾ, ਸਾਬਤ ਕੀਤਾ ਕਿ ਉਪਭੋਕਤਾਵਾਂ ਨੂੰ ਉੱਨਤ ਸੁਰੱਖਿਆ ਅਤੇ ਵਿੱਤੀ ਗੋਪਨੀਯਤਾ ਵਿਚਕਾਰ ਚੋਣ ਨਹੀਂ ਕਰਨੀ ਪੈਂਦੀ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਇਕੋਸਿਸਟਮ ਇਹਨਾਂ ਟੂਲਜ਼ ਨੂੰ ਅਪਣਾਉਂਦਾ ਹੈ, ਅਸੀਂ ਉਹਨਾਂ ਵਾਲਟ ਸਟੈਂਡਰਡਾਂ ਵੱਲ ਬਦਲਾਅ ਦੀ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹਾਂ ਜਿੱਥੇ ਸਾਰੇ ਲੈਣ-ਦੇਣ ਆਪਣੀ ਅੰਤਰੀਵ ਗੁੰਝਲਦਾਰਤਾ ਬਿਨਾਂ ਇੱਕੋ ਜਿਹੇ ਲੱਗਦੇ ਹਨ। Lightning Network ਨੂੰ ਵਧਾਉਣ ਤੋਂ ਲੈ ਕੇ Ordinals ਵਰਗੇ ਨਵੇਂ ਅਸੈੱਟ ਵਰਗਾਂ ਨੂੰ ਸੰਭਵ ਬਣਾਉਣ ਤੱਕ, Taproot ਨੇ ਬਿਟਕਾਇਨ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੇ ਡਿਜੀਟਲ ਲੈਂਡਸਕੇਪ ਵਿੱਚ ਆਪਣੀ ਸੰਬੰਧਤਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਹੈ। ਇਹ ਅਗਲੀ ਪੀੜ੍ਹੀ ਦੇ ਗੋਪਨੀਯ, ਕੁਸ਼ਲ ਅਤੇ ਪ੍ਰੋਗ੍ਰਾਮੇਬਲ ਪੈਸੇ ਲਈ ਬੁਨਿਆਦ ਦਾ ਕੰਮ ਕਰਦਾ ਹੈ।
Taproot ਅਤੇ MAST ਬਿਟਕਾਇਨ ਨੂੰ ਗੁੰਝਲਦਾਰ ਲੈਣ-ਦੇਣ ਵੇਰਵਿਆਂ ਨੂੰ ਲੁਕਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ, ਸਮਾਰਟ ਕਰਾਰਾਂ ਨੂੰ ਵਰਤਣ ਲਈ ਸਸਤੇ ਅਤੇ ਟਰੈਕ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੇ ਹਨ।