ਵ੍ਹੀਲਸੈੱਟਾਂ ਲਈ ਵੰਡਿਆ ਲੇਜ਼ਰ: ਹਾਈਪਰਲੇਜਰ ਫੈਬਰਿਕ ਨਾਲ ਅਨੁਭਵ

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

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

ਸਮੱਸਿਆ: ਬਲਾਕਚੈਨ ਅਜੇ ਤੱਕ ਸਕੇਲ ਨਹੀਂ ਕਰਦੇ ਹਨ

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

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

ਵ੍ਹਾਈਟ ਪੇਪਰ ਅਤੇ ਮੀਡੀਆ ਦੇ ਨਾਅਰੇ ਸਾਡੇ ਨਾਲ ਵਾਅਦਾ ਕਰਦੇ ਹਨ ਕਿ ਅਗਲਾ ਵਿਕਾਸ ਸਾਨੂੰ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲੱਖਾਂ ਲੈਣ-ਦੇਣ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ। ਇਹ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ?

Mainnet Ethereum ਵਰਤਮਾਨ ਵਿੱਚ ~ 30 tps 'ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ। ਇਕੱਲੇ ਇਸ ਕਰਕੇ, ਇਸ ਨੂੰ ਕਾਰਪੋਰੇਟ ਲੋੜਾਂ ਲਈ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਬਲੌਕਚੇਨ ਵਜੋਂ ਸਮਝਣਾ ਮੁਸ਼ਕਲ ਹੈ। ਅਨੁਮਤੀ ਪ੍ਰਾਪਤ ਹੱਲਾਂ ਵਿੱਚ 2000 ਟੀਪੀਐਸ ਦਿਖਾਉਂਦੇ ਹੋਏ ਬੈਂਚਮਾਰਕ ਹਨ (ਕੋਰਮਮ) ਜਾਂ 3000 tps (ਹਾਈਪਰਲੈੱਡਰ ਫੈਬਰਿਕ, ਪ੍ਰਕਾਸ਼ਨ ਵਿੱਚ ਥੋੜਾ ਘੱਟ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਬੈਂਚਮਾਰਕ ਪੁਰਾਣੇ ਸਹਿਮਤੀ ਇੰਜਣ 'ਤੇ ਕੀਤਾ ਗਿਆ ਸੀ)। ਸੀ ਰੈਡੀਕਲ ਫੈਬਰਿਕ ਪ੍ਰੋਸੈਸਿੰਗ 'ਤੇ ਇੱਕ ਕੋਸ਼ਿਸ਼, ਜਿਸ ਨੇ ਸਭ ਤੋਂ ਮਾੜੇ ਨਤੀਜੇ ਨਹੀਂ ਦਿੱਤੇ, 20000 tps, ਪਰ ਹੁਣ ਤੱਕ ਇਹ ਸਿਰਫ਼ ਅਕਾਦਮਿਕ ਖੋਜ ਹੈ, ਇਸਦੇ ਸਥਿਰ ਲਾਗੂ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਹੈ। ਇਹ ਅਸੰਭਵ ਹੈ ਕਿ ਇੱਕ ਕਾਰਪੋਰੇਸ਼ਨ ਜੋ ਬਲਾਕਚੈਨ ਡਿਵੈਲਪਰਾਂ ਦੇ ਇੱਕ ਵਿਭਾਗ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਦੀ ਸਮਰੱਥਾ ਰੱਖ ਸਕਦੀ ਹੈ, ਅਜਿਹੇ ਸੂਚਕਾਂ ਨੂੰ ਪੇਸ਼ ਕਰੇਗੀ। ਪਰ ਸਮੱਸਿਆ ਸਿਰਫ ਥ੍ਰੁਪੁੱਟ ਹੀ ਨਹੀਂ, ਲੇਟੈਂਸੀ ਵੀ ਹੈ।

ਲੈਟੈਂਸੀ

ਸਿਸਟਮ ਦੁਆਰਾ ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਸਦੀ ਅੰਤਮ ਮਨਜ਼ੂਰੀ ਤੱਕ ਦੇਰੀ ਨਾ ਸਿਰਫ਼ ਉਸ ਗਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਜਿਸ ਨਾਲ ਸੁਨੇਹਾ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਆਰਡਰਿੰਗ ਦੇ ਸਾਰੇ ਪੜਾਵਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਸਗੋਂ ਬਲਾਕ ਬਣਾਉਣ ਦੇ ਪੈਰਾਮੀਟਰਾਂ 'ਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਭਾਵੇਂ ਸਾਡਾ ਬਲਾਕਚੈਨ ਸਾਨੂੰ 1000000 tps ਦੀ ਗਤੀ ਨਾਲ ਕਮਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਪਰ 10 MB ਬਲਾਕ ਬਣਾਉਣ ਲਈ 488 ਮਿੰਟ ਦੀ ਲੋੜ ਹੈ, ਕੀ ਇਹ ਸਾਡੇ ਲਈ ਆਸਾਨ ਹੋ ਜਾਵੇਗਾ?

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

ਇੱਥੋਂ ਲਿਆ ਗਿਆ: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

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

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

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

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

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

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

ਅਗਲਾ ਕਦਮ ਹੈ ਸਿਸਟਮ ਨਾਲ ਕਲਾਇੰਟ ਦੀ ਇੰਟਰੈਕਸ਼ਨ ਨੂੰ ਅਸਿੰਕ੍ਰੋਨਸ ਬਣਾਉਣਾ ਤਾਂ ਜੋ ਇਹ 15, 30 ਜਾਂ 10000000 ਸਕਿੰਟਾਂ ਦੀ ਉਡੀਕ ਨਾ ਕਰੇ, ਜਿਸ ਨੂੰ ਅਸੀਂ BatchTimeout ਦੇ ਤੌਰ 'ਤੇ ਸੈੱਟ ਕਰਾਂਗੇ। ਪਰ ਉਸੇ ਸਮੇਂ, ਇਹ ਤਸਦੀਕ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੀਆਂ ਤਬਦੀਲੀਆਂ ਬਲਾਕਚੈਨ ਵਿੱਚ ਦਰਜ ਨਹੀਂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।
ਇੱਕ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਸਥਿਤੀ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਸਭ ਤੋਂ ਸਰਲ ਵਿਕਲਪ CouchDB ਹੈ ਇਸਦੀ ਵਰਤੋਂ ਵਿੱਚ ਆਸਾਨੀ ਦੇ ਕਾਰਨ: ਡੇਟਾਬੇਸ ਵਿੱਚ ਇੱਕ UI ਹੈ, ਇੱਕ REST API, ਅਤੇ ਤੁਸੀਂ ਇਸਦੇ ਲਈ ਆਸਾਨੀ ਨਾਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ ਸ਼ਾਰਡਿੰਗ ਸੈਟ ਕਰ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਉਸੇ CouchDB ਉਦਾਹਰਨ ਵਿੱਚ ਇੱਕ ਵੱਖਰਾ ਸੰਗ੍ਰਹਿ ਬਣਾ ਸਕਦੇ ਹੋ ਜੋ ਫੈਬਰਿਕ ਨੂੰ ਇਸਦੀ ਵਿਸ਼ਵ ਅਵਸਥਾ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਵਰਤਦਾ ਹੈ। ਸਾਨੂੰ ਇਸ ਕਿਸਮ ਦੇ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

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

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

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

ਬੈਕਪ੍ਰੈਸ਼ਰ: ਬਫਰ ਰਣਨੀਤੀ

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

ਸੰਚਾਰ ਪ੍ਰਣਾਲੀਆਂ, ਉਤਪਾਦਕ ਅਤੇ ਖਪਤਕਾਰਾਂ ਦੀ ਵੱਖ-ਵੱਖ ਸਮਰੱਥਾ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਆਓ ਦੇਖੀਏ ਕਿ ਅਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹਾਂ।

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

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

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

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

ਹੋਰ ਸਾਧਨ

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੀ ਟੀਮ ਫੈਬਰਿਕ ਦੇ ਨਾਲ ਕੰਮ ਨੂੰ ਸਰਲ ਅਤੇ ਮਜ਼ੇਦਾਰ ਬਣਾਉਣ ਲਈ ਉਪਯੋਗਤਾਵਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਵਿਕਸਿਤ ਕਰ ਰਹੀ ਹੈ: ਬਲਾਕਚੈਨ ਐਕਸਪਲੋਰਰ, ਲਈ ਇੱਕ ਉਪਯੋਗਤਾ ਆਟੋਮੈਟਿਕ ਨੈੱਟਵਰਕ ਸੰਰਚਨਾ ਤਬਦੀਲੀ (ਸੰਗਠਨਾਂ ਨੂੰ ਜੋੜਨਾ/ਹਟਾਉਣਾ, RAFT ਨੋਡ), ਲਈ ਉਪਯੋਗਤਾ ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ ਰੱਦ ਕਰਨਾ ਅਤੇ ਪਛਾਣ ਨੂੰ ਹਟਾਉਣਾ. ਜੇਕਰ ਤੁਸੀਂ ਯੋਗਦਾਨ ਪਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ।

ਸਿੱਟਾ

ਇਹ ਪਹੁੰਚ ਤੁਹਾਨੂੰ ਆਸਾਨੀ ਨਾਲ ਹਾਈਪਰਲੇਜ਼ਰ ਫੈਬਰਿਕ ਨੂੰ ਕੋਰਮ, ਹੋਰ ਪ੍ਰਾਈਵੇਟ ਈਥਰਿਅਮ ਨੈਟਵਰਕ (PoA ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ PoW) ਨਾਲ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਅਸਲ ਥ੍ਰਰੂਪੁਟ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟਾਉਂਦੀ ਹੈ, ਪਰ ਉਸੇ ਸਮੇਂ ਆਮ UX (ਦੋਵੇਂ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਉਪਭੋਗਤਾਵਾਂ ਅਤੇ ਏਕੀਕ੍ਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਲਈ) ਬਣਾਈ ਰੱਖਦੀ ਹੈ। ਸਕੀਮ ਵਿੱਚ ਫੈਬਰਿਕ ਨੂੰ Ethereum ਨਾਲ ਬਦਲਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ MVCC ਟਕਰਾਅ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਤੋਂ ਲੈ ਕੇ ਐਟਮਿਕ ਨਾਨਸ ਇਨਕਰੀਮੈਂਟ ਅਤੇ ਰੀਸੈਡਿੰਗ ਤੱਕ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਸੇਵਾ/ਸਜਾਵਟ ਕਰਨ ਵਾਲੇ ਦੇ ਤਰਕ ਨੂੰ ਬਦਲਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਬਫਰਿੰਗ ਅਤੇ ਸਟੇਟਸ ਸਟੋਰੇਜ ਨੇ ਬਲਾਕ ਬਣਾਉਣ ਦੇ ਸਮੇਂ ਤੋਂ ਜਵਾਬ ਸਮੇਂ ਨੂੰ ਡੀਕਪਲ ਕਰਨਾ ਸੰਭਵ ਬਣਾਇਆ ਹੈ। ਹੁਣ ਤੁਸੀਂ ਹਜ਼ਾਰਾਂ ਆਰਡਰ ਨੋਡ ਜੋੜ ਸਕਦੇ ਹੋ ਅਤੇ ਡਰੋ ਨਹੀਂ ਕਿ ਬਲਾਕ ਬਹੁਤ ਵਾਰ ਬਣਦੇ ਹਨ ਅਤੇ ਆਰਡਰਿੰਗ ਸੇਵਾ ਨੂੰ ਲੋਡ ਕਰਦੇ ਹਨ.

ਅਸਲ ਵਿੱਚ, ਇਹ ਸਭ ਮੈਂ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ. ਮੈਨੂੰ ਖੁਸ਼ੀ ਹੋਵੇਗੀ ਜੇਕਰ ਇਹ ਉਹਨਾਂ ਦੇ ਕੰਮ ਵਿੱਚ ਕਿਸੇ ਦੀ ਮਦਦ ਕਰਦਾ ਹੈ।

ਸਰੋਤ: www.habr.com