ਕ੍ਰਿਪਟੋ ਇਸ ਤਰ੍ਹਾਂ ਜਾਰੀ ਨਹੀਂ ਰਹਿ ਸਕਦਾ: ਇੱਕ ਬਲਾਕਚੇਨ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਵੱਲੋਂ ਉਦਯੋਗ ਦੀ ਸਵੈ-ਬਚਾਅ ਪਹਿਲਕਦਮੀ

ਇੱਕ ਘਟਨਾ ਸਿਰਫ਼ ਸੰਪਤੀਆਂ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਭਰੋਸਾ ਵੀ ਖੋਹ ਲੈਂਦੀ ਹੈ। ਕ੍ਰਿਪਟੋ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਚੱਲ ਸਕਦਾ; ਸਾਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਬਚਾਉਣਾ ਹੋਵੇਗਾ।

ਲੇਖਕ: ਰੌਬਰਟ ਮਾਓ, ਆਰਕਬਲੌਕ ਦੇ ਸੰਸਥਾਪਕ ਅਤੇ ਸੀਈਓ

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

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

29 ਅਕਤੂਬਰ, 2026 ਨੂੰ, ਬਾਇਨੈਂਸ ਵਿੱਚ ਇੱਕ ਵੱਡੀ ਸੁਰੱਖਿਆ ਘਟਨਾ ਵਾਪਰੀ। ਇਸਦੀ ਸ਼ੁਰੂਆਤੀ ਘੋਸ਼ਣਾ ਵਿੱਚ ਅਨੁਮਾਨ ਲਗਾਇਆ ਗਿਆ ਸੀ ਕਿ ਲਗਭਗ $6.3 ਬਿਲੀਅਨ ਦੀਆਂ ਸੰਪਤੀਆਂ ਪ੍ਰਭਾਵਿਤ ਹੋਈਆਂ ਸਨ, ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਸੰਪਤੀਆਂ ਵਿੱਚੋਂ ਲਗਭਗ $3 ਬਿਲੀਅਨ ਜਮ੍ਹਾਂ ਕਰ ਦਿੱਤੀਆਂ ਗਈਆਂ ਸਨ; ਜਾਂਚ ਨੇ ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਡੇਵਓਪਸ ਇੰਜੀਨੀਅਰ ਦੇ ਲੈਪਟਾਪ ਵੱਲ ਇਸ਼ਾਰਾ ਕੀਤਾ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਦਾਖਲੇ ਦੇ ਹੋਰ ਸੰਭਾਵੀ ਬਿੰਦੂ ਵੀ ਲੱਭੇ ਗਏ। ਬਾਇਨੈਂਸ ਨੇ ਇਹ ਵੀ ਕਿਹਾ ਕਿ ਵਾਲਿਟ ਪ੍ਰਾਈਵੇਟ ਕੀ ਲੀਕ ਹੋਣ ਦਾ ਕੋਈ ਸਬੂਤ ਨਹੀਂ ਮਿਲਿਆ। ਪ੍ਰਭਾਵਿਤ ਰਕਮ ਅੰਤਿਮ ਸ਼ੁੱਧ ਨੁਕਸਾਨ ਨਹੀਂ ਹੈ, ਅਤੇ ਪੂਰੀ ਹਮਲਾ ਲੜੀ ਦੀ ਜਾਂਚ ਅਜੇ ਵੀ ਜਾਰੀ ਹੈ। [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)

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

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

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

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

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

2008 ਵਿੱਚ, ਸਾਤੋਸ਼ੀ ਨਾਕਾਮੋਟੋ ਨੇ ਇੱਕ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਇਲੈਕਟ੍ਰਾਨਿਕ ਨਕਦ ਪ੍ਰਣਾਲੀ ਪ੍ਰਸਤਾਵਿਤ ਕੀਤੀ, ਜਿਸਦਾ ਉਦੇਸ਼ ਭੁਗਤਾਨਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਵਿਚੋਲਿਆਂ 'ਤੇ ਨਿਰਭਰਤਾ ਘਟਾਉਣਾ ਸੀ। [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) ਫਿਰ ਵੀ, ਉਸ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਵੱਡੀਆਂ ਘਟਨਾਵਾਂ ਨੇ ਵਾਰ-ਵਾਰ ਇਹ ਸਮੱਸਿਆ ਉਜਾਗਰ ਕੀਤੀ ਹੈ ਕਿ ਫੰਡ, ਅਧਿਕਾਰ ਅਤੇ ਸੌਫਟਵੇਅਰ ਨਿਰਭਰਤਾਵਾਂ ਦੁਬਾਰਾ ਕੇਂਦਰਿਤ ਹੋ ਰਹੀਆਂ ਹਨ।

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

2008 · ਬਿਟਕੌਇਨ ਵ੍ਹਾਈਟਪੇਪਰ

ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ

ਬਿਟਕੌਇਨ ਵ੍ਹਾਈਟਪੇਪਰ ਨੇ ਵਿੱਤੀ ਸੰਸਥਾਵਾਂ ਨੂੰ ਵਿਚੋਲੇ ਵਜੋਂ ਬਿਨਾਂ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਭੁਗਤਾਨਾਂ ਦਾ ਪ੍ਰਸਤਾਵ ਰੱਖਿਆ।

ਸਰੋਤ

2011–2014 · Mt. Gox ਲੰਮੇ ਸਮੇਂ ਦੀ ਚੋਰੀ

CEX

Mt. Gox ਨੇ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਚੋਰੀ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ ਅਤੇ ਅੰਤ ਵਿੱਚ ਕੰਮਕਾਜ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਬਾਅਦ ਵਿੱਚ ਅਮਰੀਕੀ ਨਿਆਂ ਵਿਭਾਗ ਦੇ ਇੱਕ ਦੋਸ਼ਨਾਮੇ ਵਿੱਚ ਦਾਅਵਾ ਕੀਤਾ ਗਿਆ ਕਿ 2011 ਅਤੇ 2014 ਦਰਮਿਆਨ ਲਗਭਗ 647,000 BTC ਚੋਰੀ ਹੋਏ। ਇਹ 2014 ਵਿੱਚ ਇੱਕ ਦਿਨ ਦਾ ਹਮਲਾ ਨਹੀਂ ਸੀ।

ਸਰੋਤ

2012 · Bitcoinica ਅਤੇ Bitfloor

CEX / ਕਸਟੋਡੀਅਲ ਢਾਂਚਾ

Bitcoinica ਦੇ Linode ਹੋਸਟਿੰਗ ਵਾਤਾਵਰਣ ਨਾਲ ਛੇੜਛਾੜ ਕੀਤੀ ਗਈ; ਉਸੇ ਸਾਲ, Bitfloor ਦਾ ਗੈਰ-ਐਨਕ੍ਰਿਪਟਿਡ ਵਾਲਿਟ ਬੈਕਅੱਪ ਹਮਲੇ ਦਾ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਬਣ ਗਿਆ। ਪਲੇਟਫਾਰਮ ਪਿੱਛੇ ਦੇ ਸਰਵਰ ਅਤੇ ਬੈਕਅੱਪ ਵੀ ਸੰਪਤੀ ਸੁਰੱਖਿਆ ਸੀਮਾ ਦਾ ਹਿੱਸਾ ਹਨ।

ਸਰੋਤ

2015 · Bitstamp ਹੌਟ ਵਾਲਿਟ

CEX

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

ਸਰੋਤ

2016 · Bitfinex

CEX

Bitfinex ਤੋਂ ਲਗਭਗ 120,000 BTC ਚੋਰੀ ਹੋਏ। ਮਲਟੀਸਿਗਨੇਚਰ ਪ੍ਰਬੰਧਾਂ ਲਈ ਅਜੇ ਵੀ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਸੁਤੰਤਰ ਅਧਿਕਾਰ ਅਤੇ ਤਸਦੀਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਸਰੋਤ 1 · ਸਰੋਤ 2

2016 · The DAO

ਆਨ-ਚੇਨ ਪ੍ਰੋਟੋਕੋਲ

The DAO ਕਾਂਟ੍ਰੈਕਟ 'ਤੇ ਰੀਐਂਟ੍ਰੈਂਸੀ ਹਮਲਾ ਹੋਇਆ, ਅਤੇ ਲਗਭਗ 3.6 ਮਿਲੀਅਨ ETH ਇੱਕ ਸਬ-DAO ਵਿੱਚ ਤਬਦੀਲ ਕੀਤੇ ਗਏ, ਜਿਸ ਨਾਲ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਈਥਰੀਅਮ ਫੋਰਕ ਸ਼ੁਰੂ ਹੋਇਆ। ਇੱਕ ਜਾਇਜ਼ ਐਗਜ਼ਿਕਿਊਸ਼ਨ ਮਾਰਗ ਤਬਾਹਕੁਨ ਕਾਰੋਬਾਰੀ ਨਤੀਜੇ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।

ਸਰੋਤ 1 · ਸਰੋਤ 2

2017 · Parity ਸਾਂਝੀ ਵਾਲਿਟ ਲਾਇਬ੍ਰੇਰੀ

ਕਾਂਟ੍ਰੈਕਟ ਵਾਲਿਟ

Parity ਸਾਂਝੀ ਵਾਲਿਟ ਲਾਇਬ੍ਰੇਰੀ ਨਸ਼ਟ ਕਰ ਦਿੱਤੀ ਗਈ, ਅਤੇ ਲਗਭਗ 513,000 ETH ਫ੍ਰੀਜ਼ ਹੋ ਗਏ। ਭਾਵੇਂ ਤਬਦੀਲ ਨਾ ਕੀਤੇ ਜਾਣ, ਫੰਡ ਸਾਂਝੇ ਕੋਡ ਨਿਰਭਰਤਾਵਾਂ ਕਾਰਨ ਵਰਤੋਂ ਯੋਗ ਨਹੀਂ ਰਹਿ ਸਕਦੇ।

ਸਰੋਤ

2018 · Coincheck

CEXCoincheck ਦਾ NEM ਹੌਟ ਵਾਲਿਟ ਚੋਰੀ ਹੋ ਗਿਆ। ਆਫਲਾਈਨ ਰਿਜ਼ਰਵ, ਹੌਟ ਵਾਲਿਟ ਅਨੁਮਤੀਆਂ ਅਤੇ ਕਾਰੋਬਾਰੀ ਲੋੜਾਂ ਵਿਚਕਾਰ ਸੀਮਾ ਇੱਕ ਵਾਰ ਫਿਰ ਸਮੱਸਿਆ ਬਣ ਗਈ।

ਸਰੋਤ

2019 · Binance

CEX

Binance ਨੇ ਐਲਾਨ ਕੀਤਾ ਕਿ ਇੱਕ ਹੀ ਲੈਣ-ਦੇਣ ਵਿੱਚ 7,000 BTC ਕੱਢੇ ਗਏ। ਦਸਤਖਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵੱਡੇ ਪੈਮਾਨੇ ਦੇ ਸੰਪਤੀ ਪ੍ਰਵਾਹ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਸਰੋਤ

2020 · KuCoin

CEX

KuCoin ਹੌਟ ਵਾਲਿਟ ਘਟਨਾ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਬਹੁ-ਪੱਖੀ ਸਹਿਯੋਗ ਰਾਹੀਂ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਸੰਪਤੀਆਂ ਬਰਾਮਦ ਕੀਤੀਆਂ ਗਈਆਂ। ਕੁੱਲ ਚੋਰੀ ਹੋਈ ਰਕਮ ਅਤੇ ਅੰਤਿਮ ਨੁਕਸਾਨ ਇੱਕੋ ਸੰਖਿਆ ਨਹੀਂ ਹਨ।

ਸਰੋਤ

2021 · Poly Network

ਕ੍ਰਾਸ-ਚੇਨ ਪ੍ਰੋਟੋਕੋਲ

Poly Network ਤੋਂ ਲਗਭਗ $612 ਮਿਲੀਅਨ ਦੀਆਂ ਸੰਪਤੀਆਂ ਕੱਢੀਆਂ ਗਈਆਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪੜਾਵਾਂ ਵਿੱਚ ਵਾਪਸ ਕੀਤੀਆਂ ਗਈਆਂ। ਕ੍ਰਾਸ-ਚੇਨ ਅਧਿਕਾਰ ਅਤੇ ਸੰਪਤੀ ਨਿਯੰਤਰਣ ਸਿਰਫ਼ ਆਮ ਕਾਰੋਬਾਰੀ ਮਾਰਗਾਂ ਰਾਹੀਂ ਨਹੀਂ ਟਿਕ ਸਕਦੇ।

ਸਰੋਤ

2022 · Ronin bridge

ਬ੍ਰਿਜ

Ronin ਵੈਲੀਡੇਟਰ ਅਨੁਮਤੀਆਂ ਨਾਲ ਸਮਝੌਤਾ ਹੋਇਆ, ਅਤੇ 173,600 ETH ਅਤੇ 25.5 ਮਿਲੀਅਨ USDC ਕੱਢੇ ਗਏ। ਕਈ ਵੈਲੀਡੇਟਰਾਂ ਦੀਆਂ ਕੁੰਜੀਆਂ ਵੀ ਇੱਕੋ ਹਮਲਾ ਲੜੀ ਵਿੱਚ ਫਸ ਸਕਦੀਆਂ ਹਨ।

ਸਰੋਤ

2022 · Slope wallet

ਵਾਲਿਟ

Solana ਈਕੋਸਿਸਟਮ ਵਿੱਚ Slope ਵਾਲਿਟ ਘਟਨਾ। Solana ਨੇ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ਕਿਹਾ ਕਿ ਨਿੱਜੀ ਕੁੰਜੀ ਜਾਣਕਾਰੀ ਗਲਤੀ ਨਾਲ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨਿਗਰਾਨੀ ਸੇਵਾ ਨੂੰ ਭੇਜੀ ਗਈ ਸੀ; ਇਹ Solana ਸਹਿਮਤੀ ਨਾਲ ਸਮਝੌਤਾ ਨਹੀਂ ਸੀ।

ਸਰੋਤ

2023 · Euler

ਲੈਂਡਿੰਗ ਪ੍ਰੋਟੋਕੋਲ

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

ਸਰੋਤ

2023 · Ledger Connect Kit

ਵਾਲਿਟ ਕਨੈਕਸ਼ਨ ਟੂਲ

Ledger Connect Kit 'ਤੇ ਸਪਲਾਈ ਚੇਨ ਹਮਲਾ ਹੋਇਆ, ਅਤੇ ਦੁਸ਼ਟ ਕੋਡ ਐਪਲੀਕੇਸ਼ਨ ਫਰੰਟਐਂਡ ਵਿੱਚ ਦਾਖਲ ਹੋ ਗਿਆ। ਹਾਰਡਵੇਅਰ ਡਿਵਾਈਸ ਸੁਰੱਖਿਆ ਲੈਣ-ਦੇਣ ਦੀ ਸਮੱਗਰੀ ਦੀ ਪੁਸ਼ਟੀ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦੀ।

ਸਰੋਤ

2024 · DMM Bitcoin

CEX

DMM Bitcoin ਤੋਂ ਲਗਭਗ $308 ਮਿਲੀਅਨ ਚੋਰੀ ਹੋਏ। FBI ਅਤੇ ਹੋਰ ਏਜੰਸੀਆਂ ਨੇ ਬਾਅਦ ਵਿੱਚ ਸੰਬੰਧਿਤ ਕਰਮਚਾਰੀਆਂ ਅਤੇ ਦਸਤਖਤ ਲੜੀ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਵਾਲੇ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਹਮਲਿਆਂ ਦਾ ਖੁਲਾਸਾ ਕੀਤਾ।

ਸਰੋਤ

2024 · Radiant Capital

ਲੈਂਡਿੰਗ ਪ੍ਰੋਟੋਕੋਲ / ਦਸਤਖਤ

Radiant Capital ਤੋਂ ਲਗਭਗ $50 ਮਿਲੀਅਨ ਚੋਰੀ ਹੋਏ, ਅਤੇ ਕਈ ਡਿਵੈਲਪਰ ਡਿਵਾਈਸਾਂ ਨਾਲ ਸਮਝੌਤਾ ਹੋਇਆ। ਬਹੁ-ਪੱਖੀ ਦਸਤਖਤ ਅਜੇ ਵੀ ਸਮੂਹਿਕ ਤੌਰ 'ਤੇ ਦੂਸ਼ਿਤ ਲੈਣ-ਦੇਣ ਜਾਣਕਾਰੀ 'ਤੇ ਨਿਰਭਰ ਕਰ ਸਕਦੇ ਹਨ।

ਸਰੋਤ

2025 · Bybit / Safe

CEX / ਵਾਲਿਟ ਫਰੰਟਐਂਡ

ਲਗਭਗ $1.5 ਬਿਲੀਅਨ ਦੀ Bybit ਘਟਨਾ ਵਿੱਚ Safe ਡਿਵੈਲਪਰ ਵਾਤਾਵਰਣ ਅਤੇ ਫਰੰਟਐਂਡ ਸ਼ਾਮਲ ਸਨ, ਅਤੇ ਦਸਤਖਤ ਕਰਨ ਵਾਲਿਆਂ ਨੇ ਇੱਕ ਲੈਣ-ਦੇਣ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਿਸਨੇ ਵਾਲਿਟ ਨਿਯੰਤਰਣ ਤਰਕ ਨੂੰ ਬਦਲ ਦਿੱਤਾ।

ਸਰੋਤ 1 · ਸਰੋਤ 2

2025 · Cetus DEX

DEX

Sui 'ਤੇ Cetus ਦੀ ਲਗਭਗ $223 ਮਿਲੀਅਨ ਦੀ ਘਟਨਾ, ਜਿਸ ਵਿੱਚ ਖੋਜਕਰਤਾਵਾਂ ਨੇ ਇੱਕ ਗਣਿਤ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਖਾਮੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕੀਤਾ। ਗੈਰ-EVM ਵਾਤਾਵਰਣਾਂ ਨੂੰ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਆਪਣੇ ਕੋਡ ਅਤੇ ਸੰਪਤੀ ਐਕਸਪੋਜ਼ਰ ਦੇ ਦਾਇਰੇ ਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਸਰੋਤ

2026-07 · COLDCARD ਰੈਂਡਮ ਨੰਬਰ ਖਾਮੀ

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

ਸਰੋਤ

2026-10 · Ledger ਹਾਰਡਵੇਅਰ ਇੰਪਲਾਂਟ

ਹਾਰਡਵੇਅਰ ਵਾਲਿਟ / ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਹਮਲਾ

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

ਸਰੋਤ

2026 · Binance ਮਲਟੀ-ਚੇਨ ਘਟਨਾ

CEX / ਮਲਟੀ-ਚੇਨ

Binance ਨੇ ਸ਼ੁਰੂ ਵਿੱਚ ਅਨੁਮਾਨ ਲਗਾਇਆ ਕਿ ਲਗਭਗ $6.3 ਬਿਲੀਅਨ ਦੀਆਂ ਸੰਪਤੀਆਂ ਪ੍ਰਭਾਵਿਤ ਹੋਈਆਂ, ਅਤੇ ਹੋਰ ਸੰਭਾਵਿਤ ਘੁਸਪੈਠ ਬਿੰਦੂਆਂ ਦੀ ਜਾਂਚ ਅਜੇ ਵੀ ਜਾਰੀ ਹੈ। ਇੱਕੋ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਇੱਕੋ ਸਮੇਂ ਕਈ ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਸੰਪਤੀਆਂ ਨੂੰ ਬੇਪਰਦ ਕਰ ਸਕਦਾ ਹੈ।

ਸਰੋਤ 1 · ਸਰੋਤ 2 · ਸਰੋਤ 3

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

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

Ethereum ਦਾ ਯੋਗਦਾਨ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਸਨੇ ਹੋਰ ਲੋਕਾਂ ਨੂੰ ਆਨ-ਚੇਨ ਐਪਲੀਕੇਸ਼ਨ ਲਿਖਣ ਦੇ ਯੋਗ ਬਣਾਇਆ ਅਤੇ ਟੂਲਾਂ ਅਤੇ ਡਿਵੈਲਪਮੈਂਟ ਅਨੁਭਵ ਦਾ ਇੱਕ ਅਮੀਰ ਸਮੂਹ ਪੈਦਾ ਕੀਤਾ। ਪਰ ਅੱਜ, ਬਹੁਤ ਸਾਰੇ ਨਵੇਂ ਚੇਨ ਅਤੇ L2s (ਲੇਅਰ-2 ਸਕੇਲਿੰਗ ਨੈੱਟਵਰਕ) EVM ਅਨੁਕੂਲਤਾ ਨੂੰ ਆਪਣਾ ਮੁੱਖ ਟੀਚਾ ਮੰਨਦੇ ਹਨ। EVM, ਉਹ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਜੋ Ethereum ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਚਲਾਉਂਦੀ ਹੈ, ਇੱਕ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਦੁਹਰਾਈ ਜਾਣ ਵਾਲੀ ਤਕਨੀਕੀ ਧਾਰਨਾ ਬਣ ਰਹੀ ਹੈ। ਅਨੁਕੂਲਤਾ ਐਪਲੀਕੇਸ਼ਨ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਸੁਵਿਧਾਜਨਕ ਬਣਾਉਂਦੀ ਹੈ; Unichain ਵਰਗੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ Ethereum ਟੂਲਿੰਗ ਦੇ ਮੁੜ-ਵਰਤੋਂ ਨੂੰ ਸਮਾਨ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵਾਤਾਵਰਣ ਦੇ ਮੁੱਲ ਵਜੋਂ ਦਰਸਾਉਂਦਾ ਹੈ। [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)

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

EIP-7702 ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਬਹੁਤ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ। ਇੱਕ ਆਮ ਟ੍ਰਾਂਸਫਰ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ "ਇਸ ਵਾਰ ਕਿੰਨਾ ਕਿਸਨੂੰ"; ਇੱਕ ਡੈਲੀਗੇਸ਼ਨ ਅਧਿਕਾਰ ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿ "ਹੁਣ ਤੋਂ, ਇਸ ਕੋਡ ਦੇ ਟੁਕੜੇ ਨੂੰ ਮੇਰੇ ਖਾਤੇ ਵੱਲੋਂ ਕਾਰਵਾਈਆਂ ਚਲਾਉਣ ਦਿਓ।" ਇਸਦੇ ਟੀਚੇ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਸੁਧਾਰਨਾ ਅਤੇ ਅਧਿਕਾਰਾਂ ਨੂੰ ਬਾਰੀਕ ਕਰਨਾ ਹੈ, ਪਰ ਡੈਲੀਗੇਸ਼ਨ ਸੈੱਟ ਕਰਨਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਵਿਆਪਕ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਰੱਥਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਬਾਰੀਕ-ਦਾਨੇ ਵਾਲੇ ਅਧਿਕਾਰ ਅਜੇ ਵੀ ਡੈਲੀਗੇਟ ਕੀਤੇ ਕੋਡ ਦੁਆਰਾ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) ਮਿਨਫੇਂਗ ਕੀ ਆਦਿ ਦਾ ਪ੍ਰੀਪ੍ਰਿੰਟ "EIP-7702 ਫਿਸ਼ਿੰਗ ਹਮਲਾ" ਅਜਿਹੇ ਅਧਿਕਾਰਾਂ ਨੂੰ ਸਾਈਨ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਖਾਤੇ ਨੂੰ ਲਗਾਤਾਰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਦੇ ਰਾਹ ਦਾ ਅਧਿਐਨ ਕਰਦਾ ਹੈ। [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) ਜਿਵੇਂ-ਜਿਵੇਂ ਸੁਵਿਧਾ ਵਧਦੀ ਹੈ, ਸੁਰੱਖਿਆ ਜ਼ਿੰਮੇਵਾਰੀ ਵੀ ਵਧਦੀ ਹੈ; ਪਹਿਲੀ ਨੂੰ ਸਿੱਧਾ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਨਹੀਂ ਸੌਂਪਿਆ ਜਾ ਸਕਦਾ।

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

MEV ਵੀ ਮੈਨੂੰ ਅਸੰਤੁਸ਼ਟ ਕਰਦਾ ਹੈ। ਇਹ ਉਸ ਥਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਭਾਗੀਦਾਰ ਲੈਣ-ਦੇਣਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ, ਬਾਹਰ ਕੱਢਣ, ਅਤੇ ਕ੍ਰਮਬੱਧ ਕਰਨ ਰਾਹੀਂ ਵਾਧੂ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ। ਮੇਰੇ ਲਈ, ਕ੍ਰਮਬੱਧ ਕਰਨ ਦੀ ਸ਼ਕਤੀ ਵਰਤ ਕੇ ਉਪਭੋਗਤਾ ਲੈਣ-ਦੇਣਾਂ ਨੂੰ ਸੈਂਡਵਿਚ ਕਰਨਾ ਅਤੇ ਉਹਨਾਂ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨਤੀਜਿਆਂ ਨੂੰ ਵਿਗਾੜਨਾ ਇੱਕ ਬੱਗ ਵਜੋਂ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਵਜੋਂ ਪੈਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਇਸ ਲਈ ਸੰਭਾਲਣ ਯੋਗ ਹੈ ਕਿਉਂਕਿ ਕੋਈ ਇਸ ਤੋਂ ਲਾਭ ਕਮਾ ਸਕਦਾ ਹੈ। ਈਥਰੀਅਮ ਦਾ ਆਪਣਾ ਦਸਤਾਵੇਜ਼ ਵੀ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਲੈਣ-ਦੇਣ ਸੈਂਡਵਿਚਿੰਗ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਨੁਕਸਾਨ ਅਤੇ ਨੈੱਟਵਰਕ ਸਥਿਰਤਾ ਲਈ MEV ਦੇ ਜੋਖਮ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV ਈਥਰੀਅਮ ਲਈ ਵਿਲੱਖਣ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਆਰਬਿਟਰੇਜ ਅਤੇ ਲਿਕਵਿਡੇਸ਼ਨ ਵਰਗੀਆਂ ਵੱਖ-ਵੱਖ ਗਤੀਵਿਧੀਆਂ ਵੀ ਸ਼ਾਮਲ ਹਨ; ਉਦਯੋਗ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਘਟਾਉਣ ਦੀ ਖੋਜ ਹੈ। ਮੇਰੀ ਆਲੋਚਨਾ ਇਹ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਦੀ ਪ੍ਰੇਰਣਾ ਉਪਭੋਗਤਾਵਾਂ ਦੀਆਂ ਲੈਣ-ਦੇਣ ਸ਼ਰਤਾਂ ਦੀ ਕੁਰਬਾਨੀ ਦੇਣ ਦਾ ਕਾਰਨ ਨਹੀਂ ਬਣ ਸਕਦੀ। ਇੱਕ ਬਿਹਤਰ ਲੈਣ-ਦੇਣ ਪ੍ਰਣਾਲੀ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਡਿਲੀਵਰੀ ਨਤੀਜਾ ਅਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਫੀਸਾਂ ਅਧਿਕਾਰ ਵਿੱਚ ਲਿਖਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਅਤੇ ਆਰਡਰ ਕਰਨ ਵਾਲਿਆਂ ਲਈ ਭਰੇ ਨਾ ਗਏ ਜਾਣਕਾਰੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਣ ਦੀ ਥਾਂ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।ਮੈਂ ਹਮੇਸ਼ਾ ਮਹਿਸੂਸ ਕੀਤਾ ਹੈ ਕਿ ਈਥਰੀਅਮ ਦਾ ਕ੍ਰਿਪਟੋ ਉੱਤੇ ਪ੍ਰਭਾਵ ਕੁਝ ਹੱਦ ਤੱਕ ਇੰਟਰਨੈੱਟ ਉੱਤੇ PHP ਦੇ ਪ੍ਰਭਾਵ ਵਰਗਾ ਹੈ: ਇਸਨੇ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਨੂੰ ਚੀਜ਼ਾਂ ਬਣਾਉਣ ਦੇ ਯੋਗ ਬਣਾਇਆ, ਅਤੇ ਇਸਨੇ ਇੰਜੀਨੀਅਰਿੰਗ ਕਰਜ਼ਾ ਵੀ ਛੱਡਿਆ ਜਿਸਨੂੰ ਚੁਕਾਉਣ ਵਿੱਚ ਲੰਮਾ ਸਮਾਂ ਲੱਗੇਗਾ। PHP ਨੂੰ ਅਕਤੂਬਰ 2026 ਵਿੱਚ ਅਜੇ ਵੀ ਇੱਕ ਗੰਭੀਰ ਰਿਮੋਟ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਕਮਜ਼ੋਰੀ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਸੀ। ਪਰਿਪੱਕਤਾ ਅਤੇ ਪ੍ਰਸਿੱਧੀ ਲਗਾਤਾਰ ਸਖ਼ਤੀ ਨੂੰ ਬਦਲ ਨਹੀਂ ਸਕਦੀਆਂ। [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) ਇੰਟਰਨੈੱਟ ਦੀ ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਭਾਸ਼ਾਵਾਂ, ਫਰੇਮਵਰਕ ਅਤੇ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵਿਕਸਤ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਸਾਨੂੰ ਵੱਖ-ਵੱਖ ਸੰਪਤੀ ਮਾਡਲਾਂ ਅਤੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਢੰਗਾਂ ਨੂੰ ਵੀ ਲਗਾਤਾਰ ਵਿਕਸਤ ਹੋਣ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ "ਇੱਕੋ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨਾਲ ਅਨੁਕੂਲਤਾ" ਨੂੰ ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਭਾਗ ਲੈਣ ਦੀ ਟਿਕਟ ਮੰਨਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸ ਲਈ, ਮੈਂ ਬਿਟਕੌਇਨ, ਸੋਲਾਨਾ ਅਤੇ ਰਿਪਲ/XRP ਲੈਜਰ ਈਕੋਸਿਸਟਮਾਂ, ਅਤੇ ArcBlock ਸਮੇਤ ਬਿਲਡਰਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਸੁਰੱਖਿਆ ਨੀਂਹ ਦੇ ਨਿਰਮਾਣ ਵਿੱਚ ਗੰਭੀਰਤਾ ਨਾਲ ਭਾਗ ਲੈਣ ਦੀ ਅਪੀਲ ਕਰਦਾ ਹਾਂ। ਮਾਪਦੰਡਾਂ ਅਤੇ ਇੰਟਰਓਪਰੇਬਿਲਟੀ ਵਿੱਚ ਭਾਗ ਲੈਣ ਲਈ ਪਹਿਲਾਂ ਆਪਣੇ ਆਪ ਨੂੰ ਈਥਰੀਅਮ ਵਿੱਚ ਬਦਲਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਵਿਭਿੰਨਤਾ ਨੂੰ ਸੰਪਤੀ ਨਿਯੰਤਰਣ ਅਤੇ ਤਸਦੀਕ ਢੰਗਾਂ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਜਨਤਕ ਜਾਂਚ ਲਈ ਖੁੱਲ੍ਹਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। Slope ਅਤੇ Cetus ਦੀਆਂ ਘਟਨਾਵਾਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਸਾਨੂੰ ਯਾਦ ਦਿਵਾਇਆ ਹੈ ਕਿ ਗੈਰ-EVM ਕੋਲ ਵੀ ਸੁਰੱਖਿਆ ਛੋਟ ਨਹੀਂ ਹੈ।

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

1. ਅੰਡਰਲਾਈੰਗ ਜੋਖਮ ਨਿਯੰਤਰਣਾਂ ਨੂੰ ਸੰਪਤੀਆਂ ਦਾ ਨਿਪਟਾਨ ਕਰਨ ਦੀ ਸ਼ਕਤੀ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਦਿਓ

ਵੱਡੇ ਵਾਲਿਟਾਂ ਨੂੰ ਪ੍ਰਾਪਤਕਰਤਾ ਵ੍ਹਾਈਟਲਿਸਟ, ਸੰਚਤ ਖਰਚ ਸੀਮਾਵਾਂ, ਅਤੇ ਨਵੇਂ ਪ੍ਰਾਪਤਕਰਤਾਵਾਂ ਲਈ ਉਡੀਕ ਅਵਧੀ ਸੈੱਟ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹਨਾਂ ਨਿਯਮਾਂ ਨੂੰ ਉਸੇ ਰੋਜ਼ਾਨਾ ਲੈਣ-ਦੇਣ ਕੁੰਜੀ ਦੁਆਰਾ ਤੁਰੰਤ ਰੱਦ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਨਿਯਮਾਂ ਨੂੰ ਸੋਧਣ ਲਈ ਸੁਤੰਤਰ ਅਧਿਕਾਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਨਿਗਰਾਨੀ ਅਤੇ ਰੱਦ ਕਰਨ ਲਈ ਸਮਾਂ ਛੱਡਣਾ ਚਾਹੀਦਾ ਹੈ।ਮੌਜੂਦਾ ਸਮਾਰਟ ਖਾਤਿਆਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਲਾਗੂ ਕਰਨ ਦਾ ਆਧਾਰ ਹੈ, ਉਦਾਹਰਨ ਲਈ Safe Guards ਮਲਟੀਸਿਗ ਤੋਂ ਇਲਾਵਾ ਲੈਣ-ਦੇਣ ਦੀਆਂ ਪਾਬੰਦੀਆਂ ਜੋੜ ਸਕਦਾ ਹੈ। [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) ਸਾਨੂੰ ਇਸਨੂੰ ਇੱਕ ਅਜਿਹੀ ਬੁਨਿਆਦੀ ਸਮਰੱਥਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਜਿਸਨੂੰ ਅਪਣਾਉਣਾ ਆਸਾਨ ਹੋਵੇ ਅਤੇ ਜੋ ਸਾਰੇ ਸੰਪਤੀ ਨਿਯੰਤਰਣ ਮਾਰਗਾਂ ਨੂੰ ਕਵਰ ਕਰੇ। ਜੇਕਰ ਸਿਰਫ਼ ਸਿੱਧੇ ਟ੍ਰਾਂਸਫਰਾਂ 'ਤੇ ਪਾਬੰਦੀ ਲਗਾਈ ਜਾਵੇ ਜਦਕਿ ਅਸੀਮਤ ਮਨਜ਼ੂਰੀਆਂ, ਮੌਡਿਊਲਾਂ ਜਾਂ ਅੱਪਗ੍ਰੇਡਾਂ ਰਾਹੀਂ ਬਾਈਪਾਸ ਦੀ ਆਗਿਆ ਦਿੱਤੀ ਜਾਵੇ, ਤਾਂ ਸੁਰੱਖਿਆ ਫੇਲ੍ਹ ਹੋ ਜਾਵੇਗੀ। ਵ੍ਹਾਈਟਲਿਸਟ ਕੰਟਰੈਕਟ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਪ੍ਰਾਪਤਕਰਤਾ ਦੀਆਂ ਅਨੁਮਤੀਆਂ ਬਦਲੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ, ਇਹ ਵੀ ਪੁਸ਼ਟੀਕਰਨ ਦੇ ਦਾਇਰੇ ਵਿੱਚ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ। Apple ਦਾ Activation Lock ਰੋਜ਼ਾਨਾ ਜੀਵਨ ਤੋਂ ਇੱਕ ਪ੍ਰੇਰਣਾ ਦਿੰਦਾ ਹੈ: ਇਹ ਚੋਰੀ ਹੋਏ ਯੰਤਰਾਂ ਦੇ ਮੁੜ ਸਰਗਰਮ ਹੋਣ ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਚੋਰੀ ਹੋਏ ਹਿੱਸਿਆਂ ਦੇ ਕੈਲੀਬ੍ਰੇਸ਼ਨ ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ, ਜਿਸਦਾ ਉਦੇਸ਼ ਚੋਰੀ ਤੋਂ ਬਾਅਦ ਸ਼ੋਸ਼ਣ ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲੀ ਕੀਮਤ ਨੂੰ ਘਟਾਉਣਾ ਹੈ। [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) ਵਾਲਿਟਾਂ ਨੂੰ ਵੀ ਇਸ ਦਿਸ਼ਾ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਯੋਗ ਹੈ। ਜੇਕਰ ਹਮਲਾਵਰ ਕੋਈ ਕੁੰਜੀ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਕੈਸ਼ ਆਉਟ ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲੀਆਂ ਸੰਪਤੀਆਂ ਦੀ ਸੀਮਾ ਸੀਮਤ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਹਮਲੇ ਤੋਂ ਉਮੀਦ ਕੀਤੀ ਵਾਪਸੀ ਘਟ ਸਕਦੀ ਹੈ; ਸੇਵਾਵਾਂ ਵਿੱਚ ਵਿਘਨ ਪਾਉਣ ਵਰਗੇ ਜੋਖਮਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸੰਭਾਲਣ ਦੀ ਲੋੜ ਹੈ।

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

II. ਵਾਲਿਟਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਚੁੱਕਣ ਦਿਓ, ਨਾ ਕਿ ਸਿਰਫ਼ ਮਨਮੋਨਿਕ ਸ਼ਬਦ ਸੌਂਪ ਦਿਓ

ਮੈਨੂੰ ਅੱਜ ਦੇ ਵਾਲਿਟ ਸਿਸਟਮਾਂ ਪ੍ਰਤੀ ਗਹਿਰੀ ਅਸੰਤੁਸ਼ਟੀ ਹੈ: ਜੇਕਰ ਕੋਈ ਉਤਪਾਦ ਇੱਕ ਆਮ ਵਿਅਕਤੀ ਨੂੰ ਸ਼ਬਦਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਕਾਪੀ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ, ਮੰਗ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਉਨ੍ਹਾਂ ਨੂੰ ਕਦੇ ਵੀ ਲੀਕ ਨਾ ਕਰੇ, ਗੁਆਏ ਨਾ, ਜਾਂ ਧੋਖੇ ਨਾਲ ਨਾ ਕਢਵਾਏ, ਅਤੇ ਫਿਰ ਬਾਅਦ ਦੀਆਂ ਸਾਰੀਆਂ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਉਪਭੋਗਤਾ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਠਹਿਰਾਉਂਦਾ ਹੈ, ਤਾਂ ਮੈਂ ਇਸਨੂੰ ਇੱਕ ਗੈਰ-ਜ਼ਿੰਮੇਵਾਰ ਡਿਜ਼ਾਈਨ ਮੰਨਦਾ ਹਾਂ। ਸਵੈ-ਸੰਭਾਲ ਲੋਕਾਂ ਨੂੰ ਨਿਯੰਤਰਣ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਲੋਕਾਂ ਨੂੰ ਵਰਤੋਂਯੋਗ ਸੁਰੱਖਿਆ ਅਤੇ ਰਿਕਵਰੀ ਸਮਰੱਥਾਵਾਂ ਵੀ ਦੇਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇਸਨੂੰ ਹਰ ਉਪਭੋਗਤਾ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਆ ਮਾਹਰ ਬਣਨ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ। ਇਹ ਵੀ ਇੱਕ ਥ੍ਰੈਸ਼ਹੋਲਡ ਹੈ ਜਿਸਨੂੰ Crypto ਨੂੰ ਵਧੇਰੇ ਆਮ ਉਪਭੋਗਤਾਵਾਂ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਪਾਰ ਕਰਨਾ ਹੋਵੇਗਾ।ਹਾਲੀਆ ਘਟਨਾਵਾਂ ਨੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਸਿੱਧਾ ਮੇਜ਼ 'ਤੇ ਰੱਖ ਦਿੱਤਾ ਹੈ। ਅਕਤੂਬਰ 2026 ਵਿੱਚ, Ledger ਨੇ ਪੁਸ਼ਟੀ ਕੀਤੀ ਕਿ ਹਮਲਾਵਰਾਂ ਨੇ ਅਸਲੀ ਡਿਵਾਈਸਾਂ ਵਿੱਚ ਤਬਦੀਲੀ ਕੀਤੀ ਅਤੇ ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਦੱਖਣ-ਪੂਰਬੀ ਏਸ਼ੀਆ ਵਿੱਚ ਵੰਡ ਚੈਨਲਾਂ ਰਾਹੀਂ ਬਾਜ਼ਾਰ ਵਿੱਚ ਵਾਪਸ ਭੇਜ ਦਿੱਤਾ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਲਗਾਏ ਗਏ ਕੰਪੋਨੈਂਟ ਸ਼ੁਰੂਆਤੀਕਰਨ ਦੌਰਾਨ ਰਿਕਵਰੀ ਸ਼ਬਦ ਚੋਰੀ ਕਰ ਰਹੇ ਸਨ। Ledger ਨੇ ਇਸਨੂੰ ਫੈਕਟਰੀ ਛੱਡਣ ਤੋਂ ਬਾਅਦ ਡਿਵਾਈਸ 'ਤੇ ਸਥਾਨਕ ਵੰਡ ਹਮਲਾ ਦੱਸਿਆ, ਨਾ ਕਿ ਇਸਦੇ ਚਿਪ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਜਾਂ ਸਰਵਰਾਂ ਨਾਲ ਸਮਝੌਤਾ। [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) COLDCARD ਦੀ ਜੁਲਾਈ ਘਟਨਾ ਵਿੱਚ ਫਰਮਵੇਅਰ ਕਮਜ਼ੋਰ ਕਰਨ ਵਾਲੀ ਸੀਡ ਜਨਰੇਸ਼ਨ ਸ਼ਾਮਲ ਸੀ: ਹਮਲਾਵਰ ਨੂੰ ਸੰਬੰਧਿਤ ਨਿੱਜੀ ਕੁੰਜੀਆਂ ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ ਡਿਵਾਈਸ ਨੂੰ ਰਿਮੋਟ ਤੋਂ ਨਿਯੰਤਰਿਤ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਫਰਮਵੇਅਰ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਨਾਲ ਅੱਗੇ ਵਧਣ ਲਈ ਜਨਰੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਠੀਕ ਹੋ ਜਾਂਦੀ ਹੈ, ਪਰ ਪਹਿਲਾਂ ਹੀ ਤਿਆਰ ਕੀਤੇ ਗਏ ਕਮਜ਼ੋਰ ਸੀਡਾਂ ਨੂੰ ਅਜੇ ਵੀ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)

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

ਸੁਧਾਰ ਦਾ ਟੀਚਾ ਪੂਰਾ ਵਾਲਿਟ ਜੀਵਨ ਚੱਕਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਕੁੰਜੀਆਂ ਕਿਵੇਂ ਤਿਆਰ ਹੁੰਦੀਆਂ ਹਨ, ਲੈਣ-ਦੇਣ ਕਿਵੇਂ ਸਮਝਾਏ ਜਾਂਦੇ ਹਨ, ਅਨੁਮਤੀਆਂ ਕਿਵੇਂ ਵੱਖ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਡਿਵਾਈਸ ਗੁੰਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਰਿਕਵਰੀ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਅਕਾਊਂਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨ, ਯਾਨੀ ਖਾਤਿਆਂ ਨੂੰ ਪ੍ਰੋਗਰਾਮੇਬਲ ਨਿਯਮਾਂ ਰਾਹੀਂ ਅਧਿਕਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਣਾ, ਅਤੇ SLIP-39 ਵਰਗੇ ਥ੍ਰੈਸ਼ਹੋਲਡ ਬੈਕਅੱਪ, ਦੋਵਾਂ ਦੇ ਮਿਆਰ ਅਤੇ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਨੀਂਹਾਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹਨ, ਇਸ ਲਈ ਇਹ ਨਹੀਂ ਕਿਹਾ ਜਾ ਸਕਦਾ ਕਿ ਉਦਯੋਗ ਵਿੱਚ ਕੋਈ ਵੀ ਇਨ੍ਹਾਂ 'ਤੇ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ। [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) ਪਰ ਸਾਨੂੰ ਇਹਨਾਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਪਰਖੀਆਂ ਹੋਈਆਂ, ਵਰਤਣ ਵਿੱਚ ਆਸਾਨ ਸੁਰੱਖਿਆਵਾਂ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਨਾ ਕਿ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਜਟਿਲ ਸਕੀਮਾਂ ਜੋੜਨ ਦੀ ਲੋੜ ਹੋਵੇ।

ਨਿਮੋਨਿਕ ਸ਼ਬਦਾਂ ਦਾ ਸਧਾਰਨ ਧੁੰਦਲਾਪਣ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਸਮੀਖਿਆ ਕੀਤੇ ਗਏ ਐਨਕ੍ਰਿਪਟਡ ਬੈਕਅੱਪ, ਥ੍ਰੈਸ਼ਹੋਲਡ ਰਿਕਵਰੀ, ਅਤੇ ਸੁਤੰਤਰ ਡਿਵਾਈਸ ਅਧਿਕਾਰ ਸ਼ਾਮਲ ਹਨ, ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਸੰਪਤੀਆਂ ਜਮ੍ਹਾਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰਿਕਵਰੀ ਅਭਿਆਸ ਪੂਰੇ ਕਰਨ ਦੇਣਾ। ਬੈਕਅੱਪ ਸ਼ਾਰਡ ਅਤੇ ਮਲਟੀਸਿਗ ਵੱਖ-ਵੱਖ ਪਰਤਾਂ ਹਨ: ਪਹਿਲਾ ਰਿਕਵਰੀ ਦੌਰਾਨ ਉਸੇ ਰਹੱਸ ਵਿੱਚ ਦੁਬਾਰਾ ਜੁੜ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਦੂਜੇ ਲਈ ਲੈਣ-ਦੇਣ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਲਈ ਕਈ ਸੁਤੰਤਰ ਸਾਈਨਰਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਰਿਕਵਰੀ ਸੇਵਾਵਾਂ ਚੁੱਪਚਾਪ ਨਵੀਂ ਮਾਸਟਰ ਕੁੰਜੀ ਨਹੀਂ ਬਣਨੀਆਂ ਚਾਹੀਦੀਆਂ, ਅਤੇ ਨਾ ਹੀ ਵਾਧੂ ਪਾਸਵਰਡ ਇੱਕ ਹੋਰ ਜਾਲ ਬਣਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਇਸਨੂੰ ਗੁਆਉਣ ਦਾ ਮਤਲਬ ਅਣਪਛਾਤਾ ਨੁਕਸਾਨ ਹੋਵੇ।ਪਰਸਨਲ ਵਾਲਿਟ ਅਤੇ ਐਕਸਚੇਂਜ ਵਾਲਿਟ ਸਿਸਟਮ ਲੈਣ-ਦੇਣ ਦੇ ਵੇਰਵਿਆਂ, ਸਾਈਨਿੰਗ ਬੇਨਤੀਆਂ, ਸੰਪਤੀ ਪਾਬੰਦੀਆਂ ਅਤੇ ਰਿਕਵਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸਾਂਝੀਆਂ ਕਰ ਸਕਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਵੱਖ-ਵੱਖ ਸੀਮਾਵਾਂ ਅਤੇ ਮਨਜ਼ੂਰੀ ਨੀਤੀਆਂ ਅਪਣਾ ਸਕਦੇ ਹਨ। ਬਿਟਕਾਇਨ ਦਾ PSBT ਪਹਿਲਾਂ ਹੀ ਟੂਲਾਂ ਵਿੱਚ ਅਣ-ਸਾਈਨ ਕੀਤੇ ਲੈਣ-ਦੇਣ ਪਾਸ ਕਰਨ ਲਈ ਇੱਕ ਫਾਰਮੈਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਆਮ ਇੰਟਰਫੇਸ ਬਣਾਉਣਾ ਜਾਰੀ ਰੱਖਣਾ ਯੋਗ ਹੈ। [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) ਜੋ ਆਮ ਹੈ ਉਹ ਹੈ ਜਾਂਚਯੋਗ ਸੁਰੱਖਿਆ ਲੋੜਾਂ; ਹਰੇਕ ਚੇਨ ਨੂੰ ਅਜੇ ਵੀ ਆਪਣੇ ਆਪਣੇ ਅਨੁਕੂਲਨ ਨਿਯਮ ਸਪਸ਼ਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਵਾਲਿਟਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਪੇਸ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਦਸਤਖਤ ਕੀ ਟ੍ਰਾਂਸਫਰ ਕਰਨਗੇ ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਕਿਸ ਨੂੰ ਕਿੰਨਾ ਅਧਿਕਾਰ ਦਿੱਤਾ ਜਾਵੇਗਾ, ਅਤੇ ਸੁਤੰਤਰ ਨੀਤੀਆਂ ਨੂੰ ਸੀਮਾ ਤੋਂ ਬਾਹਰ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਰੱਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ; ਇੱਕ ਵਧੀਆ ਦਿਖਣ ਵਾਲਾ ਪੁਸ਼ਟੀਕਰਨ ਪੰਨਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ।

III. ਘੱਟੋ-ਘੱਟ ਲੋੜੀਂਦੇ ਖੁਲਾਸੇ ਨਾਲ ਜਾਂਚਯੋਗਤਾ ਪ੍ਰਾਪਤ ਕਰੋ

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

W3C ਦੀ ਪ੍ਰਮਾਣਿਤ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਚੋਣਾਤਮਕ ਖੁਲਾਸੇ ਲਈ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਤਕਨੀਕੀ ਰਾਹ ਹੈ; ਹਾਲਾਂਕਿ, ਇਹ ਸਾਬਤ ਕਰਨਾ ਕਿ ਇਨਪੁਟ ਪ੍ਰਮਾਣਿਕ ਹਨ, ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵੈਧ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਸਥਿਤੀ ਕਿਵੇਂ ਰੱਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਜੇ ਵੀ ਸਪਸ਼ਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) ਜ਼ੀਰੋ-ਨਾਲੇਜ ਸਬੂਤ (ZK) ਅਪਣਾਉਣ ਨਾਲ ਆਪਣੇ ਆਪ ਲੈਣ-ਦੇਣ ਦੀਆਂ ਰਕਮਾਂ ਅਤੇ ਸੰਬੰਧ ਲੁਕਦੇ ਨਹੀਂ; ਸਕੇਲਿੰਗ ਸਬੂਤ ਅਤੇ ਗੋਪਨੀਯਤਾ ਸੁਰੱਖਿਆ ਵੱਖ-ਵੱਖ ਟੀਚੇ ਹਨ।

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

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

IV. ਲੈਣ-ਦੇਣ ਸੇਵਾਵਾਂ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਕੇਂਦਰੀਕ੍ਰਿਤ ਸੰਭਾਲ ਤੋਂ ਮੁਕਤ ਬਣਾਓਵਪਾਰ ਮਿਲਾਨ, ਮਾਰਗ ਖੋਜ, ਅਤੇ ਸੰਪਤੀ ਨਿਪਟਾਰਾ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਵਪਾਰਕ ਐਂਟਰੀ ਪੁਆਇੰਟ ਪ੍ਰਦਾਨ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਅਧਿਕਾਰ ਮਿਲਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਮੌਜੂਦਾ ਨਿਪਟਾਰਾ ਪੂਰਾ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਹਨ, ਤਾਂ ਜੋ ਬਾਕੀ ਸਮੇਂ ਉਪਭੋਗਤਾ ਦੀਆਂ ਸੰਪਤੀਆਂ ਉਨ੍ਹਾਂ ਦੇ ਆਪਣੇ ਨਿਯੰਤਰਣ ਹੇਠ ਰਹਿਣ। ਮੌਜੂਦਾ ਇਰਾਦਾ-ਅਧਾਰਿਤ ਲੈਣ-ਦੇਣ ਪ੍ਰੋਟੋਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇਸ ਮਾਰਗ ਦਾ ਕੁਝ ਹਿੱਸਾ ਖੋਜ ਚੁੱਕੇ ਹਨ, ਅਤੇ ਉਦਯੋਗ ਇਸਨੂੰ ਪੂਰਾ ਕਰਨਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ। [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)

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

IBIT iShares ਦਾ ਬਿਟਕੌਇਨ ਐਕਸਚੇਂਜ-ਟ੍ਰੇਡਿਡ ਉਤਪਾਦ ਹੈ, ਅਤੇ ਬਾਜ਼ਾਰ ਵਿੱਚ ਜੋ ਵਪਾਰ ਹੁੰਦਾ ਹੈ ਉਹ ਇਸਦੇ ਸ਼ੇਅਰ ਹਨ। ਇਸਦਾ ਪ੍ਰਬੰਧ ਅੰਸ਼ਕ ਅਲੱਗਾਵ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ: ਸ਼ੇਅਰ ਅਤੇ ਅੰਡਰਲਾਈੰਗ ਬਿਟਕੌਇਨ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦਰਜ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ Vault Balance (ਕਸਟਡੀ ਬੈਲੰਸ) ਲਈ ਸੰਬੰਧਿਤ ਪ੍ਰਾਈਵੇਟ ਕੀਜ਼ ਕੋਲਡ ਸਟੋਰੇਜ ਵਿੱਚ ਰੱਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਸ਼ੇਅਰ ਵਪਾਰ ਰਿਕਾਰਡ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਲਈ ਲੋੜ ਨਹੀਂ ਕਿ ਅੰਡਰਲਾਈੰਗ ਬਿਟਕੌਇਨ ਹਰ ਲੈਣ-ਦੇਣ ਨਾਲ ਹਿਲੇ। [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) ਇਸ ਤੋਂ ਜੋ ਸਿੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਉਹ ਹੈ ਵਪਾਰਕ ਅਧਿਕਾਰਾਂ ਅਤੇ ਰਿਜ਼ਰਵ ਨਿਪਟਾਰਾ ਅਧਿਕਾਰਾਂ ਦਾ ਵੱਖਰਾਪਣ। ਇਸਦੇ Trading Balance (ਵਪਾਰਕ ਸੇਵਾ ਬੈਲੰਸ) ਦਾ ਪ੍ਰਬੰਧ ਵੱਖਰਾ ਹੈ, ਅਤੇ ਕਸਟਡੀ ਆਪਣੇ ਆਪ ਵਿੱਚ ਵੀ ਜੋਖਮ ਰੱਖਦੀ ਹੈ; ਕੋਲਡ ਸਟੋਰੇਜ ਨੂੰ ਸੁਤੰਤਰ ਨਿਰਦੇਸ਼ ਅਤੇ ਦਸਤਖਤ ਪੁਸ਼ਟੀਕਰਨ ਨਾਲ ਜੋੜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

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

V. ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਅਲੱਗ ਕਰਨ ਅਤੇ ਬਦਲਣਯੋਗਤਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਲਈ ਪਰਤਦਾਰ ਆਰਕੀਟੈਕਚਰ ਦੀ ਵਰਤੋਂ ਕਰੋਸਾਨੂੰ ਪਹਿਚਾਣ ਅਤੇ ਅਧਿਕਾਰ ਦੇ ਇੰਟਰਫੇਸ, ਸੰਪਤੀ ਨੀਤੀਆਂ, ਅਤੇ ਨਿਪਟਾਰੇ ਦੀ ਪੁਸ਼ਟੀ ਦੇ ਤਰੀਕੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਵਿਕਸਤ ਹੋ ਸਕਣ। ਵੱਖ-ਵੱਖ ਚੇਨ ਆਪਣੇ ਖੁਦ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮਾਡਲ ਰੱਖ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਸਪਸ਼ਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਜੁੜ ਸਕਦੀਆਂ ਹਨ। ਇੰਟਰਫੇਸ ਨੂੰ ਸੁਰੱਖਿਆ ਦੀਆਂ ਗਰੰਟੀਆਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀਆਂ ਸ਼ਰਤਾਂ ਦੱਸਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਹਿਣਾ ਚਾਹੀਦਾ ਕਿ "ਕਾਲ ਸਫਲ ਹੋ ਗਈ।"ਇੰਟਰਨੈੱਟ ਦਾ ਤਜਰਬਾ ਇਸ ਪਹੁੰਚ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। RFC 9518, "ਕੇਂਦਰੀਕਰਨ, ਵਿਕੇਂਦਰੀਕਰਨ, ਅਤੇ ਇੰਟਰਨੈੱਟ ਮਿਆਰ" ਵਿੱਚ, ਮਾਰਕ ਨੌਟਿੰਘਮ ਖਾਸ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਬਾਰੇ ਚਰਚਾ ਕਰਦੇ ਹਨ ਜਿੱਥੇ ਕੇਂਦਰੀਕਰਨ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਵੀ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹਨ ਕਿ ਇਹ ਕਿਹੜੀ ਸ਼ਕਤੀ ਅਤੇ ਜੋਖਮ ਲਿਆਉਂਦਾ ਹੈ। [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) ਇਹ ਬਿਲਕੁਲ ਉਹ ਰਵੱਈਆ ਹੈ ਜਿਸ ਤੋਂ ਸਿੱਖਣਾ ਚਾਹੀਦਾ ਹੈ: ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਜਵਾਬ ਦੇਣ ਦਿਓ ਕਿ ਕਿਹੜੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਕਿਸ ਹੱਦ ਤੱਕ, ਅਤੇ ਉਸ ਸ਼ਕਤੀ ਨੂੰ ਵਧਣ ਤੋਂ ਕਿਵੇਂ ਰੋਕਿਆ ਜਾਵੇ। ਇੱਕ ਸੇਵਾ ਨੂੰ ਵਿਸੰਗਤੀਆਂ ਨੂੰ ਕੇਂਦਰੀ ਤੌਰ 'ਤੇ ਪਛਾਣਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਸੰਪਤੀਆਂ ਨੂੰ ਛੂਹਣ ਦੀ ਇਸਦੀ ਇਜਾਜ਼ਤ ਸੀਮਿਤ ਹੋਵੇ; ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਆਪਣੀਆਂ ਸੰਪਤੀ ਨੀਤੀਆਂ ਅਤੇ ਪੁਸ਼ਟੀ ਰਿਕਾਰਡ ਗੁਆਏ ਬਿਨਾਂ ਸੇਵਾਵਾਂ ਬਦਲਣ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

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

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

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

6. ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਆਪਣੀਆਂ ਸੰਪਤੀਆਂ ਨੂੰ ਹਲਕੇ ਤੌਰ 'ਤੇ ਪੁਸ਼ਟੀ ਕਰਨ ਦਿਓ

ਆਮ ਲੋਕਾਂ ਨੂੰ ਆਪਣੇ ਬੈਲੰਸ ਅਤੇ ਰਸੀਦਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਪੂਰੀ ਚੇਨ ਦਾ ਸਾਰਾ ਇਤਿਹਾਸ ਸਟੋਰ ਅਤੇ ਐਗਜ਼ੀਕਿਊਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ; ਨਾ ਹੀ ਉਨ੍ਹਾਂ ਨੂੰ ਵਾਲਿਟ ਪਿੱਛੇ ਸਿਰਫ਼ ਇੱਕ ਸਰਵਰ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਸਤੋਸ਼ੀ ਨਾਕਾਮੋਟੋ ਨੇ ਵ੍ਹਾਈਟਪੇਪਰ ਦੇ ਸੈਕਸ਼ਨ 8 ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ SPV, ਸਰਲ ਭੁਗਤਾਨ ਪੁਸ਼ਟੀ, ਪ੍ਰਸਤਾਵਿਤ ਕੀਤੀ ਸੀ। ਬਿਟਕੌਇਨ ਦਾ BIP-157 ਕਲਾਇੰਟਾਂ ਨੂੰ ਫਿਲਟਰ ਡਾਊਨਲੋਡ ਕਰਨ ਅਤੇ ਆਪਣੇ ਨਾਲ ਸੰਬੰਧਿਤ ਬਲਾਕ ਲੱਭਣ ਦੇਣ ਦੀ ਖੋਜ ਜਾਰੀ ਰੱਖਦਾ ਹੈ; ਈਥਰੀਅਮ ਵਿੱਚ ਵੀ ਹਲਕੇ ਕਲਾਇੰਟ ਡਿਜ਼ਾਈਨ ਹਨ। [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) ਇਸ ਲਈ ਸਮੱਸਿਆ ਇਹ ਨਹੀਂ ਕਿ ਕਿਸੇ ਨੇ ਕਦੇ ਇਸ ਬਾਰੇ ਸੋਚਿਆ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਸਾਨੂੰ ਅਜੇ ਵੀ ਸਪਸ਼ਟ ਸੁਰੱਖਿਆ ਸ਼ਰਤਾਂ ਵਾਲੀ ਪੁਸ਼ਟੀ ਸਮਰੱਥਾ ਨੂੰ ਉਨ੍ਹਾਂ ਵਾਲਿਟਾਂ ਵਿੱਚ ਬਣਾਉਣਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਹਰ ਰੋਜ਼ ਵਰਤਦੇ ਹਨ।ਇੱਕ ਚੇਨ ਨੂੰ ਉਦਾਹਰਨ ਵਜੋਂ ਲਓ ਜੋ ਖਾਤਾ ਸਥਿਤੀ ਸਬੂਤਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ: ਬੈਲੰਸ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰਦੇ ਸਮੇਂ, ਸਰਵਰ ਨੂੰ ਬੈਲੰਸ ਅਤੇ ਇੱਕ ਸਬੂਤ ਦੋਵੇਂ ਵਾਪਸ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਵਾਲਿਟ ਪਹਿਲਾਂ ਉਸ ਚੇਨ ਦੇ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਇੱਕ ਛੋਟਾ ਬਲਾਕ ਡਾਇਜੈਸਟ, ਭਾਵ ਬਲਾਕ ਹੈਡਰ, ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਜਾਂਚਦਾ ਹੈ ਕਿ ਕੀ ਇਹ ਬੈਲੰਸ ਡਾਇਜੈਸਟ ਦੁਆਰਾ ਪ੍ਰਤੀਬੱਧ ਡੇਟਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਸਰਵਰ ਜਵਾਬ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਵਾਲਿਟ ਜਵਾਬ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ। ਬਿਟਕੌਇਨ ਦਾ SPV ਸਬੂਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਸੰਬੰਧਿਤ ਲੈਣ-ਦੇਣ ਸ਼ਾਮਲ ਸਨ; ਇਸਨੂੰ ਸਿੱਧਾ ਬੈਲੰਸ ਸਬੂਤ ਵਜੋਂ ਨਕਲ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਵਾਲਿਟ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਇਹ ਵੀ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਕਿੱਥੇ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਹੋਇਆ ਹੈ ਅਤੇ ਕਿਹੜੀ ਜਾਣਕਾਰੀ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਹੈ; ਜਦੋਂ ਸਬੂਤ ਗੁੰਮ ਹੋਣ, ਡੇਟਾ ਪੁਰਾਣਾ ਹੋਵੇ, ਜਾਂ ਸਰੋਤ ਟਕਰਾਉਣ, ਤਾਂ ਇਸਨੂੰ ਚੇਤਾਵਨੀ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਇਸ ਜਾਣਕਾਰੀ 'ਤੇ ਨਿਰਭਰ ਉੱਚ-ਜੋਖਮ ਵਾਲੇ ਕਾਰਜਾਂ ਨੂੰ ਰੋਕਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਚੁੱਪਚਾਪ ਅੰਨ੍ਹੇ ਭਰੋਸੇ 'ਤੇ ਵਾਪਸ ਨਹੀਂ ਆਉਣਾ ਚਾਹੀਦਾ।

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

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

7. ਅਸਧਾਰਨਤਾ ਪਛਾਣ ਅਤੇ ਸੁਰੱਖਿਆ ਪੁਸ਼ਟੀ ਨੂੰ ਜਨਤਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਜੋਂ ਬਣਾਓ

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

ਉਸੇ ਸਮੇਂ, ਸਾਨੂੰ ਹਮਲੇ ਦੇ ਕੇਸਾਂ, ਅਨੁਮਤੀ ਟੈਸਟਾਂ, ਅਤੇ ਵਾਰ-ਵਾਰ ਚਲਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਪੁਸ਼ਟੀ ਟੂਲਾਂ ਨੂੰ ਸਾਂਝੇ ਤੌਰ 'ਤੇ ਬਣਾਈ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ। ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਾਂਝਾ ਕਰਕੇ ਅਤੇ ਸੁਤੰਤਰ ਲਾਗੂਕਰਨ ਅਤੇ ਸੁਤੰਤਰ ਪੁਸ਼ਟੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖ ਕੇ ਹੀ ਕਾਮਨ-ਮੋਡ ਫੇਲ੍ਹ ਹੋਣ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਫਾਊਂਡੇਸ਼ਨਾਂ ਅਤੇ ਐਕਸਚੇਂਜਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸੁਰੱਖਿਆ ਨਿਵੇਸ਼ ਹਨ, ਜਿਵੇਂ ਕਿ ਈਥਰੀਅਮ ਫਾਊਂਡੇਸ਼ਨ ਦੀ ਟ੍ਰਿਲੀਅਨ ਡਾਲਰ ਸਿਕਿਓਰਿਟੀ ਇਨੀਸ਼ੀਏਟਿਵ। [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) ਅਗਲਾ ਸਵਾਲ ਇਹ ਪੁੱਛਣਾ ਹੈ ਕਿ ਕੀ ਨਿਵੇਸ਼ ਨੂੰ ਜਨਤਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਹੋਰ ਟੀਮਾਂ ਵੀ ਅਪਣਾ ਅਤੇ ਜਾਂਚ ਸਕਣ।ਇਹਨਾਂ ਸੱਤ ਕੰਮਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪੂਰਨ ਸੁਰੱਖਿਆ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦੇ ਸਕਦਾ। ਇਹਨਾਂ ਨੂੰ ਜੋ ਦੇਣਾ ਹੈ ਉਹ ਹੈ ਜਾਂਚਯੋਗ ਸੀਮਾਵਾਂ: ਕਿਹੜੀਆਂ ਸ਼ਰਤਾਂ ਅਧੀਨ ਇਜਾਜ਼ਤ ਦਾ ਸਮਝੌਤਾ ਹੁੰਦਾ ਹੈ, ਵੱਧ ਤੋਂ ਵੱਧ ਕਿੰਨੀ ਜਾਇਦਾਦ ਬੇਪਰਦਾ ਹੁੰਦੀ ਹੈ, ਅਸਧਾਰਨਤਾਵਾਂ ਕਿੰਨੀ ਜਲਦੀ ਖੋਜੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਰਿਕਵਰੀ ਅਜੇ ਵੀ ਕਿਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

ਇਸ ਮੋੜ 'ਤੇ, ਕੁਝ ਲੋਕ ਕਹਿ ਸਕਦੇ ਹਨ: ਦਿਸ਼ਾ ਸਹੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਉਦਯੋਗ ਪਹਿਲਾਂ ਹੀ ਕਈ ਸਾਲਾਂ ਤੋਂ ਚੱਲ ਰਿਹਾ ਹੈ; ਮੁੜ ਨਿਰਮਾਣ ਲਈ ਕਿੰਨੇ ਲੋਕ ਅਤੇ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗੇਗਾ? ਕੀ ਇਹ ਅਜੇ ਵੀ ਆਦਰਸ਼ਵਾਦ ਨਹੀਂ ਹੈ?

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

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

Anthropic ਅਤੇ PNNL ਦੀ ਖੋਜ ਇੱਕ ਠੋਸ ਉਦਾਹਰਨ ਦਿੰਦੀ ਹੈ: ਇੱਕ ਸੀਮਿਤ ਨਾਜ਼ੁਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਸਿਮੂਲੇਸ਼ਨ ਵਾਤਾਵਰਣ ਵਿੱਚ, ਖੋਜਕਰਤਾਵਾਂ ਨੇ ਰਿਪੋਰਟ ਕੀਤਾ ਕਿ ਹਮਲੇ ਦਾ ਮੁੜ ਨਿਰਮਾਣ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਕਈ ਹਫ਼ਤਿਆਂ ਤੋਂ ਘਟਾ ਕੇ ਲਗਭਗ ਤਿੰਨ ਘੰਟੇ ਹੋ ਗਿਆ। [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਇੱਕ ਛੋਟੀ ਟੀਮ ਪਹਿਲਾਂ ਹੀ ਪੂਰੇ ਉਦਯੋਗ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਮੁੜ ਲਿਖ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਪਹਿਲਾਂ ਮਹਿੰਗੇ ਤਸਦੀਕ ਅਤੇ ਹਮਲਾ-ਰੱਖਿਆ ਕਾਰਜਾਂ ਦੀਆਂ ਨਵੀਆਂ ਲਾਗਤ ਸ਼ਰਤਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।

ਇੱਕ ਸੰਗਠਨਾਤਮਕ ਪਹੁੰਚ ਜੋ ਹੁਣ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਉਹ ਹੈ ਸਾਂਝੇ ਤੌਰ 'ਤੇ ਇੱਕ Build in Public AI Factory ਬਣਾਉਣਾ। ਉਦਯੋਗ ਮਾਹਰ, ਵਿਦਵਾਨ ਅਤੇ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਲੋੜਾਂ ਅਤੇ ਸਵੀਕ੍ਰਿਤੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (spec) ਲਿਖਦੇ ਹਨ, ਇਹ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਹੈ, ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਅਤੇ ਕਿਹੜੀਆਂ ਇਜਾਜ਼ਤਾਂ ਦੇ ਸਮਝੌਤੇ ਤੋਂ ਬਾਅਦ ਕਿਹੜੀਆਂ ਸੀਮਾਵਾਂ ਅਜੇ ਵੀ ਕਾਇਮ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਅਤੇ ਫਿਰ ਇਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਸਵੀਕ੍ਰਿਤੀ ਟੈਸਟਾਂ ਵਿੱਚ ਬਦਲਦੇ ਹਨ। ਕੋਡਿੰਗ ਏਜੰਟਾਂ ਦੇ ਸਮੂਹ ਮੁੱਖ ਕੋਡਿੰਗ, ਟੈਸਟਿੰਗ ਅਤੇ ਡੀਬੱਗਿੰਗ ਦਾ ਕੰਮ ਲੈਂਦੇ ਹਨ; ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਡਿਜ਼ਾਈਨ ਅਤੇ ਨਤੀਜਿਆਂ ਦੀ ਜਾਂਚ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਮਨੁੱਖ ਨਿਰਣੇ ਅਤੇ ਸਵੀਕ੍ਰਿਤੀ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਂਦੇ ਹਨ।ਭਾਗੀਦਾਰ ਵਿਚਾਰ, ਮਸ਼ੀਨਾਂ, ਕੰਪਿਊਟਿੰਗ ਪਾਵਰ ਅਤੇ ਮਾਡਲ ਇਨਵੋਕੇਸ਼ਨ ਕੋਟਾ, ਯਾਨੀ AI ਟੋਕਨ, ਦਾ ਯੋਗਦਾਨ ਪਾ ਸਕਦੇ ਹਨ। AI ਅਤੇ ਕਲਾਉਡ ਕੰਪਿਊਟਿੰਗ ਕੰਪਨੀਆਂ ਵੀ ਮਾਡਲ ਕੋਟਾ, ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਅਤੇ ਟੂਲਾਂ ਰਾਹੀਂ ਇਸ ਜਨਤਕ ਨਿਰਮਾਣ ਦਾ ਸਮਰਥਨ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਸਪੈਕਸ, ਪ੍ਰੋਟੋਟਾਈਪ ਕੋਡ, ਏਜੰਟ ਵਰਕਫਲੋ, ਟੈਸਟ ਵਾਤਾਵਰਣ ਅਤੇ ਪਰਖ ਨਤੀਜੇ ਸਾਰੇ ਆਮ ਤੌਰ 'ਤੇ ਸੰਭਾਲੀ ਜਾਣ ਵਾਲੀ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਅਗਲੀ ਟੀਮ ਸਿੱਧੀ ਉੱਥੋਂ ਹੀ ਅੱਗੇ ਵਧ ਸਕਦੀ ਹੈ। ਟੀਚਾ ਹੈ ਵਿਕਾਸ ਸਮਰੱਥਾ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤੋਂ ਯੋਗ ਜਨਤਕ ਸਹੂਲਤਾਂ ਵਿੱਚ ਬਦਲਣਾ ਅਤੇ ਕਿਸੇ ਇੱਕ ਵਿਅਕਤੀ ਦੇ ਸਮੇਂ ਜਾਂ ਕਿਸੇ ਇੱਕ ਟੀਮ 'ਤੇ ਨਿਰਭਰਤਾ ਘਟਾਉਣਾ।

ਹਮਲਾਵਰ ਵੀ AI ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ, ਅਤੇ ਸਾਡੇ ਕੋਲ ਹੁਣ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਹੈ ਕਿ ਬਚਾਅ ਨੂੰ ਪਿਛਲੇ ਜ਼ਮਾਨੇ ਦੇ ਉਤਪਾਦਨ ਢੰਗਾਂ ਵਿੱਚ ਛੱਡ ਦੇਈਏ। [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) ਪਰ ਕੋਡ ਜਨਰੇਸ਼ਨ ਦਾ ਤੇਜ਼ ਹੋਣਾ ਸਿਰਫ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੈ। ਸਿਰਫ ਪਾਬੰਦੀਆਂ ਸਪਸ਼ਟ ਲਿਖ ਕੇ, ਟੈਸਟਾਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਚਲਾਉਣ ਯੋਗ ਬਣਾ ਕੇ, ਅਤੇ ਕਿਸੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਜਾਂਚਯੋਗ ਅਤੇ ਬਦਲਣਯੋਗ ਬਣਾ ਕੇ ਹੀ AI ਸਮਰੱਥਾ ਨੂੰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਸੁਧਾਰ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।

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

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

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

ਸਾਨੂੰ ਮਿਲ ਕੇ ਇਸ ਕਿਸਮ ਦਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ, ਭਾਵੇਂ ਕੋਈ ਹਿੱਸਾ ਸਮਝੌਤਾ ਹੋ ਚੁੱਕਾ ਹੋਵੇ, ਸੰਪਤੀਆਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਜੇ ਵੀ ਬਣੀਆਂ ਰਹਿਣ, ਹੋਰ ਸਿਸਟਮ ਅਜੇ ਵੀ ਗਲਤੀਆਂ ਨੂੰ ਰੱਦ ਕਰ ਸਕਣ, ਅਤੇ ਵਰਤੋਂਕਾਰਾਂ ਕੋਲ ਅਜੇ ਵੀ ਰਿਕਵਰੀ ਅਤੇ ਨਿਕਾਸ ਦੇ ਰਾਹ ਹੋਣ। ਸਟਾਰ ਵਾਰਜ਼ ਤੋਂ ਨਾਮ ਉਧਾਰ ਲੈਂਦਿਆਂ, ਇਹ ਸਾਡੀ A New Hope ਹੈ। [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) ਉਮੀਦ ਉਨ੍ਹਾਂ ਆਮ ਨਿਰਮਾਤਾਵਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ ਜੋ ਕਾਰਵਾਈ ਕਰਨ ਲਈ ਤਿਆਰ ਹਨ, ਅਤੇ ਇਸ ਪਲ ਤੋਂ ਵੀ ਜਦੋਂ ਕੋਡਿੰਗ ਏਜੰਟ ਅਤੇ ਨਵੇਂ ਇੰਜੀਨੀਅਰਿੰਗ ਢੰਗ ਉਨ੍ਹਾਂ ਨੂੰ ਵਧੇਰੇ ਨਿਰਮਾਣ ਕੰਮ ਲੈਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।ਮੈਂ Ethereum, Solana, Bitcoin, ਅਤੇ XRP Ledger ਵਰਗੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਬਿਲਡਰਾਂ, Binance, Coinbase, ਅਤੇ Kraken ਵਰਗੇ ਐਕਸਚੇਂਜਾਂ, ਅਤੇ ਨਾਲ ਹੀ ਵਾਲਿਟ, ਪ੍ਰੋਟੋਕੋਲ, ਸੁਰੱਖਿਆ ਖੋਜ, AI, ਅਤੇ ਕਲਾਉਡ ਕੰਪਿਊਟਿੰਗ ਟੀਮਾਂ ਨੂੰ ਸੱਦਾ ਦੇਣਾ ਚਾਹੁੰਦਾ ਹਾਂ: ਇੱਕ ਸਪਸ਼ਟ ਦਾਇਰੇ ਵਾਲੇ ਪਾਇਲਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਾਂਝੇ ਤੌਰ 'ਤੇ ਸੁਧਾਰ ਤਿਆਰ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹੋਰ ਟੀਮਾਂ ਅਪਣਾ ਅਤੇ ਪਰਖ ਸਕਣ।

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

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

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

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

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

Crypto ਇਸ ਤਰ੍ਹਾਂ ਜਾਰੀ ਨਹੀਂ ਰਹਿ ਸਕਦਾ। ਜੋ ਇਕੱਠੇ ਕੰਮ ਕਰਨ ਲਈ ਤਿਆਰ ਹਨ, ਆਓ ਅਸੀਂ ਹੁਣ ਕਾਰਵਾਈ ਕਰੀਏ, ਇੱਕ ਅਜਿਹੇ ਸੁਧਾਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ ਜੋ ਬਣਾਇਆ ਜਾ ਸਕੇ ਅਤੇ ਪਰਖ ਨੂੰ ਝੱਲ ਸਕੇ।ਬਿਨਾਂਸ, ਸ਼ੁਰੂਆਤੀ ਘੋਸ਼ਣਾ ਅਧਿਕਾਰਤ ਪੋਸਟ ਅਤੇ ਫਾਲੋ-ਅੱਪ ਜਾਂਚ ਅਧਿਕਾਰਤ ਅੱਪਡੇਟ, 2026-10-30; TRM ਮਲਟੀ-ਚੇਨ ਵਿਸ਼ਲੇਸ਼ਣ। ਇਹ ਡਰਾਫਟ 2026-10-30 ਤੱਕ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਗਿਆ ਸੀ; ਜਾਂਚ ਅਤੇ ਰਿਕਵਰੀ ਸਥਿਤੀ ਬਦਲ ਸਕਦੀ ਹੈ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)

ਸਤੋਸ਼ੀ ਨਾਕਾਮੋਟੋ, ਬਿਟਕੋਇਨ: ਇੱਕ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਇਲੈਕਟ੍ਰਾਨਿਕ ਨਕਦ ਪ੍ਰਣਾਲੀ, 2008। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)

ਯੂਨੀਸਵੈਪ, ਯੂਨੀਚੇਨ EVM ਸਮਾਨਤਾ। ਸਾਂਝੇ ਨਿਰਭਰਤਾਵਾਂ ਦੀ ਜੋਖਮ ਇਕਾਗਰਤਾ ਇਸ ਲੇਖ ਵਿੱਚ ਲੇਖਕ ਦਾ ਨਿਰਣਾ ਹੈ, ਉਸ ਦਸਤਾਵੇਜ਼ ਦਾ ਸਿੱਟਾ ਨਹੀਂ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)

ਵਿਟਾਲਿਕ ਬੁਟੇਰਿਨ, ਸੈਮ ਵਿਲਸਨ, ਐਨਸਗਰ ਡੀਟ੍ਰਿਚਸ, ਲਾਈਟਕਲਾਈਂਟ, EIP-7702: EOAs ਲਈ ਕੋਡ ਸੈੱਟ ਕਰੋ, ਬਣਾਇਆ ਗਿਆ 2024-05-07। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)

ਮਿਨਫੈਂਗ ਕੀ, ਕਿਨ ਵੈਂਗ, ਰੂਈਕਿਆਂਗ ਲੀ, ਤਿਆਨਕਿੰਗ ਝੂ, ਸ਼ਿਪਿੰਗ ਚੇਨ, EIP-7702 ਫਿਸ਼ਿੰਗ ਹਮਲਾ, 2025-12-13, arXiv v1 ਪ੍ਰੀਪ੍ਰਿੰਟ; ਇਹ ਬਿਨਾਂਸ ਘਟਨਾ ਦੀ ਪਛਾਣ ਨਹੀਂ ਹੈ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)

ਈਥਰੀਅਮ, ਅਧਿਕਤਮ ਕੱਢਣ ਯੋਗ ਮੁੱਲ (MEV), ਆਰਡਰਿੰਗ ਵਿਧੀਆਂ, ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ, ਅਤੇ ਨਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵ; "ਇਸਨੂੰ ਬੱਗ ਵਜੋਂ ਠੀਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ" ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਣ ਵਾਲੇ ਵਿਵਹਾਰ ਬਾਰੇ ਲੇਖਕ ਦਾ ਇੰਜੀਨੀਅਰਿੰਗ ਰੁਖ ਹੈ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)

PHP ਅਧਿਕਾਰਤ 2026 ਨਿਊਜ਼ ਆਰਕਾਈਵ; CISA 2026-10-26 ਜਾਣੇ-ਪਛਾਣੇ ਸ਼ੋਸ਼ਿਤ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਅੱਪਡੇਟ, CVE-2026-109618, CVE-2026-109619। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)

ਸੇਫ, ਗਾਰਡਸ ਅਤੇ ਮੌਡਿਊਲਸ, ਕਾਰਜਕੁਸ਼ਲਤਾ ਅਤੇ ਅਨੁਮਤੀ ਜੋਖਮਾਂ ਦਾ ਵੇਰਵਾ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)

ਐਪਲ, ਐਪਲ ਵਰਤੇ ਗਏ ਅਸਲੀ ਹਿੱਸਿਆਂ ਲਈ ਸਹਾਇਤਾ ਨਾਲ ਮੁਰੰਮਤ ਦੇ ਵਿਕਲਪਾਂ ਦਾ ਵਿਸਤਾਰ ਕਰੇਗਾ, 2024-04-11; ਮੌਜੂਦਾ ਹਿੱਸਿਆਂ ਦੀ ਜੋੜੀ ਬਣਾਉਣ ਸਹਾਇਤਾ ਦਾ ਵੇਰਵਾ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)ਲੈਜਰ, ਹਾਰਡਵੇਅਰ ਇੰਪਲਾਂਟ ਹਮਲੇ ਲਈ ਲੈਜਰ ਦਾ ਜਵਾਬ, 2026-10, ਵੰਡ ਲੜੀ ਵਿੱਚ ਇੱਕ ਹਮਲੇ ਬਾਰੇ ਵਿਕਰੇਤਾ ਦਾ ਬਿਆਨ; ਜੋ ਗ੍ਰੈਂਡ, ਹਾਰਡਵੇਅਰ ਇੰਪਲਾਂਟਾਂ 'ਤੇ ਰਿਵਰਸ ਇੰਜੀਨੀਅਰਿੰਗ ਖੋਜ। ਅਣ-ਪ੍ਰਮਾਣਿਤ ਨੈੱਟਵਰਕ ਨੁਕਸਾਨ ਅਨੁਮਾਨਾਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਸਿੱਟਿਆਂ ਵਜੋਂ ਪੇਸ਼ ਨਾ ਕਰੋ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)

ਕੋਇਨਕਾਈਟ, ਮੌਜੂਦਾ COLDCARD ਸੁਰੱਖਿਆ ਸਥਿਤੀ, 2026-10-30 ਨੂੰ ਐਕਸੈਸ ਕੀਤਾ ਗਿਆ, ਜੁਲਾਈ 2026 ਘਟਨਾ ਅਤੇ ਸੁਧਾਰ ਦਾ ਲਗਾਤਾਰ ਅੱਪਡੇਟ ਕੀਤਾ ਰਿਕਾਰਡ; ਅੱਪਗ੍ਰੇਡ ਕਰਨਾ ਅਤੇ ਸੀਡ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੋ ਵੱਖਰੀਆਂ ਕਾਰਵਾਈਆਂ ਹਨ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)

ERC-4337: ਆਲਟ ਮੈਂਪੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਖਾਤਾ ਐਬਸਟ੍ਰੈਕਸ਼ਨ; ਟ੍ਰੇਜ਼ਰ, SLIP39 ਆਮ ਸਵਾਲ, ਥ੍ਰੈਸ਼ਹੋਲਡ ਰਿਕਵਰੀ, ਅਨੁਕੂਲਤਾ, ਅਤੇ ਵਾਧੂ ਪਾਸਫ੍ਰੇਜ਼ ਜੋਖਮ। ਮੌਜੂਦਾ ਵਿਧੀਆਂ ਬਣਾਉਣ ਲਈ ਇੱਕ ਨੀਂਹ ਹਨ, ਅਤੇ ਇਹ ਨਹੀਂ ਦਰਸਾਉਂਦੀਆਂ ਕਿ ਹਰ ਤੈਨਾਤੀ ਭਰੋਸੇਯੋਗ ਹੈ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਹਸਤਾਖਰਿਤ ਬਿਟਕੌਇਨ ਲੈਣ-ਦੇਣ ਫਾਰਮੈਟ, ਬਿਨਾਂ ਹਸਤਾਖਰਿਤ ਲੈਣ-ਦੇਣ ਲਈ ਇੱਕ ਐਕਸਚੇਂਜ ਫਾਰਮੈਟ, ਕੋਈ ਕ੍ਰਾਸ-ਚੇਨ ਆਮ ਸੰਪਤੀ ਰਣਨੀਤੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)

W3C, ਪ੍ਰਮਾਣਿਤ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਸੰਖੇਪ v1.0, 2026-07-30 ਗਰੁੱਪ ਨੋਟ; ਈਥਰੀਅਮ ਪਰਦੇਦਾਰੀ ਨੋਟਸ। ਸੰਖੇਪ ਵਿੱਚ ਦੱਸੀਆਂ ਗਈਆਂ ਤਕਨੀਕਾਂ ਦੀ ਮਿਆਰ ਸਥਿਤੀ ਹਰ ਮਾਮਲੇ ਵਿੱਚ ਸੁਤੰਤਰ ਹੈ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)

CoW ਪ੍ਰੋਟੋਕੋਲ ਦਸਤਾਵੇਜ਼, ਲੈਣ-ਦੇਣ ਦੇ ਇਰਾਦੇ ਅਤੇ ਸੋਲਵਰ ਵਿਧੀਆਂ; ਇਹ ਲੇਖ ਕਿਸੇ ਵੀ ਖਾਸ ਡਿਪਲੌਇਮੈਂਟ ਲਈ ਵਿਆਪਕ ਸੁਰੱਖਿਆ ਸਮਰਥਨ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)

iShares, IBIT 2025 ਸਾਲਾਨਾ ਰਿਪੋਰਟ, PDF ਪੰਨੇ 8–10 ਕਸਟਡੀ ਪ੍ਰਬੰਧ ਅਤੇ ਪੰਨਾ 45 ਜੋਖਮ ਖੁਲਾਸੇ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)

Mark Nottingham, RFC 9518: ਕੇਂਦਰੀਕਰਨ, ਵਿਕੇਂਦਰੀਕਰਨ, ਅਤੇ ਇੰਟਰਨੈੱਟ ਮਿਆਰ, 2023-12, ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਜਮ੍ਹਾਂ ਕੀਤਾ ਗਿਆ, ਸੂਚਨਾਤਮਕ RFC, ਮਿਆਰ-ਟ੍ਰੈਕ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)

ਬਿਟਕੌਇਨ ਵ੍ਹਾਈਟਪੇਪਰ ਭਾਗ 8 ਸਰਲ ਭੁਗਤਾਨ ਪ੍ਰਮਾਣਿਕਤਾ; BIP-157: ਕਲਾਇੰਟ ਸਾਈਡ ਬਲਾਕ ਫਿਲਟਰਿੰਗ; ਈਥਰੀਅਮ, ਲਾਈਟ ਕਲਾਇੰਟਸ। ਵੱਖ-ਵੱਖ ਲਾਈਟ ਕਲਾਇੰਟਸ ਦੇ ਪ੍ਰਮਾਣਿਕਤਾ ਦਾਇਰੇ ਅਤੇ ਭਰੋਸਾ ਸ਼ਰਤਾਂ ਵੱਖਰੀਆਂ ਹਨ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)

ਈਥਰੀਅਮ ਫਾਊਂਡੇਸ਼ਨ, ਟ੍ਰਿਲੀਅਨ ਡਾਲਰ ਸੁਰੱਖਿਆ ਪਹਿਲਕਦਮੀ ਦੀ ਘੋਸ਼ਣਾ, 2025-05-14। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)

Anthropic, ਨਾਜ਼ੁਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਰੱਖਿਆ ਲਈ AI, 2026-01-08, PNNL ਦੇ ਸਹਿਯੋਗ ਨਾਲ ਸੀਮਿਤ-ਵਾਤਾਵਰਣ ਖੋਜ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)

Anthropic, AI-ਸਮਰੱਥ ਸਾਈਬਰ ਖਤਰਿਆਂ ਦਾ ਨਕਸ਼ਾ ਬਣਾਉਣਾ, ਅਸਲ ਦੁਰਵਰਤੋਂ ਦੇ ਨਮੂਨਿਆਂ 'ਤੇ ਖੋਜ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)

Lucasfilm, ਸਟਾਰ ਵਾਰਜ਼: ਏ ਨਿਊ ਹੋਪ (ਐਪੀਸੋਡ IV), 1977; ਇਹ ਲੇਖ ਸਿਰਲੇਖ ਅਤੇ ਸਾਂਝੇ ਸਵੈ-ਬਚਾਅ ਦੀ ਬਿੰਬ-ਵਿਧੀ ਉਧਾਰ ਲੈਂਦਾ ਹੈ। [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)