ਜਨਤਕ ਟੈਸਟ: Ethereum 'ਤੇ ਗੋਪਨੀਯਤਾ ਅਤੇ ਸਕੇਲੇਬਿਲਟੀ ਲਈ ਇੱਕ ਹੱਲ

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

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

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

ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਵਿੱਚ ਮੁੱਖ ਪ੍ਰਕਿਰਿਆਵਾਂ

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

2. ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਇਵੈਂਟਸ ਲਈ ਸਬਸਕ੍ਰਾਈਬ ਕੀਤੇ ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਨੋਡਸ ਇੱਕ ਡਿਪਾਜ਼ਿਟ ਬਣਾਉਣ ਬਾਰੇ ਇੱਕ ਇਵੈਂਟ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਅਤੇ ਪੂਲ ਵਿੱਚ ਇੱਕ ਟੋਕਨ ਬਣਾਉਣ ਬਾਰੇ ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਜੋੜਦੇ ਹਨ।

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

4. ਬਲਾਕ ਸਬਮਿਸ਼ਨ ਇਵੈਂਟ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੋਡ ਉਹਨਾਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ ਜੋ ਬਲਾਕ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਨ।

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

6. ਜੇਕਰ ਟੋਕਨ ਕਢਵਾਉਣ ਦੀ ਕਾਰਵਾਈ ਉਲੰਘਣਾਵਾਂ ਨਾਲ ਹੋਈ ਹੈ (ਟੋਕਨ ਕਢਵਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਖਰਚ ਕੀਤਾ ਗਿਆ ਸੀ ਜਾਂ ਟੋਕਨ ਕਢਵਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਹੋਰ ਦਾ ਸੀ), ਟੋਕਨ ਦਾ ਮਾਲਕ ਦੋ ਹਫ਼ਤਿਆਂ ਦੇ ਅੰਦਰ ਕਢਵਾਉਣ ਦਾ ਖੰਡਨ ਕਰ ਸਕਦਾ ਹੈ।

ਗੋਪਨੀਯਤਾ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ

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

2. ਚਾਈਲਡ ਚੇਨ zk-SNARKs ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਗਿਆਤ ਲੈਣ-ਦੇਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ।

ਤਕਨਾਲੋਜੀ ਸਟੈਕ

• ਨੋਡਜ ਐਸ
• ਰੇਡਿਸ
• ਈਥਰਿਅਮ
• ਮਿੱਟੀ

ਟੈਸਟਿੰਗ

ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਦਾ ਵਿਕਾਸ ਕਰਦੇ ਸਮੇਂ, ਅਸੀਂ ਸਿਸਟਮ ਦੀ ਗਤੀ ਦੀ ਜਾਂਚ ਕੀਤੀ ਅਤੇ ਹੇਠਾਂ ਦਿੱਤੇ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕੀਤੇ:

• ਪ੍ਰਤੀ ਸਕਿੰਟ 35 ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਪੂਲ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ;
• ਇੱਕ ਬਲਾਕ ਵਿੱਚ 1 ਤੱਕ ਲੈਣ-ਦੇਣ ਸਟੋਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਹੇਠਾਂ ਦਿੱਤੇ 3 ਸਰਵਰਾਂ 'ਤੇ ਟੈਸਟ ਕੀਤੇ ਗਏ ਸਨ:

1. ਇੰਟੇਲ ਕੋਰ i7-6700 ਕਵਾਡ-ਕੋਰ ਸਕਾਈਲੇਕ ਸਮੇਤ। NVMe SSD - 512 GB, 64 GB DDR4 ਰੈਮ
3 ਪ੍ਰਮਾਣਿਤ ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਨੋਡਸ ਨੂੰ ਉਭਾਰਿਆ ਗਿਆ ਸੀ।

2. AMD Ryzen 7 1700X Octa-core “Summit Ridge” (Zen), SATA SSD – 500 GB, 64 GB DDR4 ਰੈਮ
ਰੋਪਸਟਨ ਟੈਸਟਨੈੱਟ ETH ਨੋਡ ਨੂੰ ਉਭਾਰਿਆ ਗਿਆ ਸੀ।
3 ਪ੍ਰਮਾਣਿਤ ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਨੋਡਸ ਨੂੰ ਉਭਾਰਿਆ ਗਿਆ ਸੀ।

3. Intel Core i9-9900K ਔਕਟਾ-ਕੋਰ ਸਮੇਤ। NVMe SSD - 1 TB, 64 GB DDR4 ਰੈਮ
1 ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਸਬਮਿਸ਼ਨ ਨੋਡ ਵਧਾਇਆ ਗਿਆ ਸੀ।
3 ਪ੍ਰਮਾਣਿਤ ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਨੋਡਸ ਨੂੰ ਉਭਾਰਿਆ ਗਿਆ ਸੀ।
ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਨੈਟਵਰਕ ਵਿੱਚ ਲੈਣ-ਦੇਣ ਜੋੜਨ ਲਈ ਇੱਕ ਟੈਸਟ ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ ਸੀ।

ਕੁੱਲ: ਇੱਕ ਪ੍ਰਾਈਵੇਟ ਨੈੱਟਵਰਕ ਵਿੱਚ 10 ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਨੋਡਸ।

ਟੈਸਟ 1

ਪ੍ਰਤੀ ਬਲਾਕ 1 ਮਿਲੀਅਨ ਲੈਣ-ਦੇਣ ਦੀ ਸੀਮਾ ਹੈ। ਇਸ ਲਈ, 1 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ 2 ਬਲਾਕਾਂ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ (ਕਿਉਂਕਿ ਸਿਸਟਮ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦਾ ਹਿੱਸਾ ਲੈਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਭੇਜੇ ਜਾਣ ਵੇਲੇ ਜਮ੍ਹਾਂ ਕਰਨ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ)।

ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ: ਆਖਰੀ ਬਲਾਕ #7; 1 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਅਤੇ ਟੋਕਨ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਗਏ ਹਨ।

00:00 - ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਜਨਰੇਸ਼ਨ ਸਕ੍ਰਿਪਟ ਦੀ ਸ਼ੁਰੂਆਤ
01:37 - 1 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਬਣਾਏ ਗਏ ਅਤੇ ਨੋਡ ਨੂੰ ਭੇਜਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ
01:46 — ਸਬਮਿਟ ਨੋਡ ਨੇ ਪੂਲ ਅਤੇ ਫਾਰਮ ਬਲਾਕ #240 ਤੋਂ 8k ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਏ। ਅਸੀਂ ਇਹ ਵੀ ਦੇਖਦੇ ਹਾਂ ਕਿ 320k ਲੈਣ-ਦੇਣ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਪੂਲ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ
01:58 — ਬਲਾਕ #8 ਸਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਲਈ ਭੇਜਿਆ ਗਿਆ ਹੈ
02:03 — ਬਲਾਕ #8 ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਦੇ `ਸਬਮਿਟਬਲਾਕ` ਫੰਕਸ਼ਨ ਨੂੰ ਮਰਕਲ ਹੈਸ਼ ਅਤੇ ਬਲਾਕ ਨੰਬਰ ਨਾਲ ਕਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
02:10 — ਡੈਮੋ ਸਕ੍ਰਿਪਟ ਨੇ ਕੰਮ ਕਰਨਾ ਖਤਮ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਨੇ 1 ਸਕਿੰਟਾਂ ਵਿੱਚ 32 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਭੇਜੇ।
02:33 - ਨੋਡਸ ਨੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ ਕਿ ਬਲਾਕ #8 ਨੂੰ ਰੂਟ ਚੇਨ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ, ਅਤੇ 240k ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ
02:40 - 240k ਲੈਣ-ਦੇਣ ਪੂਲ ਤੋਂ ਹਟਾ ਦਿੱਤੇ ਗਏ ਸਨ, ਜੋ ਪਹਿਲਾਂ ਹੀ ਬਲਾਕ #8 ਵਿੱਚ ਹਨ
02:56 — ਸਬਮਿਟ ਨੋਡ ਨੇ ਬਾਕੀ ਬਚੇ 760k ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਪੂਲ ਤੋਂ ਲਿਆ ਅਤੇ Merkle ਹੈਸ਼ ਅਤੇ ਸਾਈਨਿੰਗ ਬਲਾਕ #9 ਦੀ ਗਣਨਾ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ।
03:20 - ਸਾਰੇ ਨੋਡਸ ਵਿੱਚ 1 ਮਿਲੀਅਨ 240k ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਅਤੇ ਟੋਕਨ ਹੁੰਦੇ ਹਨ
03:35 — ਬਲਾਕ #9 ਸਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਹੋਰ ਨੋਡਸ ਨੂੰ ਵੈਲੀਡੇਸ਼ਨ ਲਈ ਭੇਜਿਆ ਗਿਆ ਹੈ
03:41 - ਨੈੱਟਵਰਕ ਐਰਰ ਆਈ ਹੈ
04:40 — ਬਲਾਕ #9 ਵੈਲੀਡੇਸ਼ਨ ਦੀ ਉਡੀਕ ਦਾ ਸਮਾਂ ਸਮਾਪਤ ਹੋ ਗਿਆ ਹੈ
04:54 — ਸਬਮਿਟ ਨੋਡ ਨੇ ਬਾਕੀ ਬਚੇ 760k ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਪੂਲ ਤੋਂ ਲਿਆ ਅਤੇ Merkle ਹੈਸ਼ ਅਤੇ ਸਾਈਨਿੰਗ ਬਲਾਕ #9 ਦੀ ਗਣਨਾ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ।
05:32 — ਬਲਾਕ #9 ਸਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਹੋਰ ਨੋਡਸ ਨੂੰ ਵੈਲੀਡੇਸ਼ਨ ਲਈ ਭੇਜਿਆ ਗਿਆ ਹੈ
05:53 — ਬਲਾਕ #9 ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਰੂਟ ਚੇਨ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ
06:17 - ਨੋਡਸ ਨੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ ਹੈ ਕਿ ਬਲਾਕ #9 ਨੂੰ ਰੂਟ ਚੇਨ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ ਅਤੇ 760k ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ
06:47 — ਪੂਲ ਨੇ ਉਹਨਾਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਸਾਫ਼ ਕਰ ਦਿੱਤਾ ਹੈ ਜੋ ਬਲਾਕ #9 ਵਿੱਚ ਹਨ
09:06 - ਸਾਰੇ ਨੋਡਸ ਵਿੱਚ 2 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਅਤੇ ਟੋਕਨ ਹੁੰਦੇ ਹਨ

ਟੈਸਟ 2

ਪ੍ਰਤੀ ਬਲਾਕ 350k ਦੀ ਸੀਮਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡੇ ਕੋਲ 3 ਬਲਾਕ ਹਨ.

ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ: ਆਖਰੀ ਬਲਾਕ #9; 2 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਅਤੇ ਟੋਕਨ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਗਏ ਹਨ

00:00 — ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਜਨਰੇਸ਼ਨ ਸਕ੍ਰਿਪਟ ਪਹਿਲਾਂ ਹੀ ਲਾਂਚ ਕੀਤੀ ਜਾ ਚੁੱਕੀ ਹੈ
00:44 - 1 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਬਣਾਏ ਗਏ ਅਤੇ ਨੋਡ ਨੂੰ ਭੇਜਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ
00:56 — ਸਬਮਿਟ ਨੋਡ ਨੇ ਪੂਲ ਅਤੇ ਫਾਰਮ ਬਲਾਕ #320 ਤੋਂ 10k ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਏ। ਅਸੀਂ ਇਹ ਵੀ ਦੇਖਦੇ ਹਾਂ ਕਿ 320k ਲੈਣ-ਦੇਣ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਪੂਲ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ
01:12 — ਬਲਾਕ #10 ਸਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਲਈ ਹੋਰ ਨੋਡਸ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ
01:18 — ਡੈਮੋ ਸਕ੍ਰਿਪਟ ਨੇ ਕੰਮ ਕਰਨਾ ਖਤਮ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਨੇ 1 ਸਕਿੰਟਾਂ ਵਿੱਚ 34 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਭੇਜੇ।
01:20 — ਬਲਾਕ #10 ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਰੂਟ ਚੇਨ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ
01:51 - ਸਾਰੇ ਨੋਡਸ ਰੂਟ ਚੇਨ ਤੋਂ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਜੋ ਬਲਾਕ #10 ਨੂੰ ਜੋੜਿਆ ਗਿਆ ਸੀ ਅਤੇ 320k ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ
02:01 - ਪੂਲ ਨੇ 320k ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਲਈ ਕਲੀਅਰ ਕੀਤਾ ਹੈ ਜੋ ਬਲਾਕ #10 ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਨ
02:15 — ਸਬਮਿਟ ਨੋਡ ਨੇ ਪੂਲ ਅਤੇ ਫਾਰਮ ਬਲਾਕ #350 ਤੋਂ 11k ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਏ
02:34 — ਬਲਾਕ #11 ਸਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਲਈ ਦੂਜੇ ਨੋਡਸ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ
02:51 — ਬਲਾਕ #11 ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਰੂਟ ਚੇਨ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ
02:55 — ਆਖਰੀ ਨੋਡ ਨੇ ਬਲਾਕ #10 ਤੋਂ ਲੈਣ-ਦੇਣ ਨੂੰ ਪੂਰਾ ਕੀਤਾ
10:59 — ਬਲਾਕ #9 ਨੂੰ ਜਮ੍ਹਾਂ ਕਰਾਉਣ ਦੇ ਨਾਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਰੂਟ ਚੇਨ ਵਿੱਚ ਬਹੁਤ ਲੰਮਾ ਸਮਾਂ ਲੱਗਿਆ, ਪਰ ਇਹ ਪੂਰਾ ਹੋ ਗਿਆ ਅਤੇ ਸਾਰੇ ਨੋਡਸ ਨੇ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕੀਤੀ ਅਤੇ 350k ਲੈਣ-ਦੇਣ ਕਰਨੇ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੇ।
11:05 - ਪੂਲ ਨੇ 320k ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਲਈ ਕਲੀਅਰ ਕੀਤਾ ਹੈ ਜੋ ਬਲਾਕ #11 ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਨ
12:10 - ਸਾਰੇ ਨੋਡਾਂ ਵਿੱਚ 1 ਮਿਲੀਅਨ 670k ਲੈਣ-ਦੇਣ ਅਤੇ ਟੋਕਨ ਹੁੰਦੇ ਹਨ
12:17 — ਸਬਮਿਟ ਨੋਡ ਨੇ ਪੂਲ ਅਤੇ ਫਾਰਮ ਬਲਾਕ #330 ਤੋਂ 12k ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਏ
12:32 — ਬਲਾਕ #12 ਸਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਲਈ ਦੂਜੇ ਨੋਡਸ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ
12:39 — ਬਲਾਕ #12 ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਰੂਟ ਚੇਨ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ
13:44 - ਸਾਰੇ ਨੋਡਸ ਰੂਟ ਚੇਨ ਤੋਂ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਜੋ ਬਲਾਕ #12 ਨੂੰ ਜੋੜਿਆ ਗਿਆ ਸੀ ਅਤੇ 330k ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ
14:50 - ਸਾਰੇ ਨੋਡਸ ਵਿੱਚ 2 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਅਤੇ ਟੋਕਨ ਹੁੰਦੇ ਹਨ

ਟੈਸਟ 3

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

ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ: ਆਖਰੀ ਬਲਾਕ #84; ਡੇਟਾਬੇਸ ਵਿੱਚ 0 ਲੈਣ-ਦੇਣ ਅਤੇ ਟੋਕਨ ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਗਏ ਹਨ

00:00 — 3 ਸਕ੍ਰਿਪਟਾਂ ਲਾਂਚ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ ਜੋ ਹਰੇਕ 1 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਤਿਆਰ ਅਤੇ ਭੇਜਦੀਆਂ ਹਨ
01:38 — 1 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਬਣਾਏ ਗਏ ਅਤੇ ਨੋਡ #3 ਨੂੰ ਸਬਮਿਟ ਕਰਨ ਲਈ ਭੇਜਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ
01:50 — ਸਬਮਿਟ ਨੋਡ #3 ਨੇ ਪੂਲ ਅਤੇ ਫਾਰਮ ਬਲਾਕ #330 (f85) ਤੋਂ 21k ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਏ। ਅਸੀਂ ਇਹ ਵੀ ਦੇਖਦੇ ਹਾਂ ਕਿ 350k ਲੈਣ-ਦੇਣ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਪੂਲ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ
01:53 — 1 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਬਣਾਏ ਗਏ ਅਤੇ ਨੋਡ #1 ਨੂੰ ਸਬਮਿਟ ਕਰਨ ਲਈ ਭੇਜਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ
01:50 — ਸਬਮਿਟ ਨੋਡ #3 ਨੇ ਪੂਲ ਅਤੇ ਫਾਰਮ ਬਲਾਕ #330 (f85) ਤੋਂ 21k ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਏ। ਅਸੀਂ ਇਹ ਵੀ ਦੇਖਦੇ ਹਾਂ ਕਿ 350k ਲੈਣ-ਦੇਣ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਪੂਲ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ
02:01 — ਸਬਮਿਟ ਨੋਡ #1 ਨੇ ਪੂਲ ਤੋਂ 250k ਲੈਣ-ਦੇਣ ਕੀਤੇ ਅਤੇ ਬਲਾਕ #85 (65e) ਨੂੰ ਫਾਰਮ ਦਿੱਤਾ।
02:06 — ਬਲਾਕ #85 (f21) ਸਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਲਈ ਹੋਰ ਨੋਡਸ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ।
02:08 — ਸਰਵਰ #3 ਦੀ ਡੈਮੋ ਸਕ੍ਰਿਪਟ, ਜਿਸ ਨੇ 1 ਸਕਿੰਟਾਂ ਵਿੱਚ 30 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਭੇਜੇ, ਕੰਮ ਕਰਨਾ ਖਤਮ ਹੋ ਗਿਆ।
02:14 — ਬਲਾਕ #85 (f21) ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਰੂਟ ਚੇਨ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ।
02:19 — ਬਲਾਕ #85 (65e) ਤੇ ਹਸਤਾਖਰ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਹੋਰ ਨੋਡਸ ਨੂੰ ਭੇਜੇ ਗਏ ਹਨ।
02:22 — 1 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਬਣਾਏ ਗਏ ਅਤੇ ਨੋਡ #2 ਨੂੰ ਸਬਮਿਟ ਕਰਨ ਲਈ ਭੇਜਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ
02:27 — ਬਲਾਕ #85 (65e) ਪ੍ਰਮਾਣਿਤ ਅਤੇ ਰੂਟ ਚੇਨ ਨੂੰ ਭੇਜਿਆ ਗਿਆ
02:29 — ਸਬਮਿਟ ਨੋਡ #2 ਨੇ ਪੂਲ ਤੋਂ 111855 ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਏ ਅਤੇ ਬਲਾਕ #85 (256) ਨੂੰ ਫਾਰਮ ਦਿੱਤਾ।
02:36 — ਬਲਾਕ #85 (256) ਤੇ ਹਸਤਾਖਰ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਹੋਰ ਨੋਡਸ ਨੂੰ ਭੇਜੇ ਗਏ ਹਨ।
02:36 — ਸਰਵਰ #1 ਦੀ ਡੈਮੋ ਸਕ੍ਰਿਪਟ, ਜਿਸ ਨੇ 1 ਸਕਿੰਟਾਂ ਵਿੱਚ 42.5 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਭੇਜੇ, ਕੰਮ ਕਰਨਾ ਖਤਮ ਹੋ ਗਿਆ।
02:38 — ਬਲਾਕ #85 (256) ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਰੂਟ ਚੇਨ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ।
03:08 — ਸਰਵਰ #2 ਸਕ੍ਰਿਪਟ ਨੇ ਕੰਮ ਕਰਨਾ ਪੂਰਾ ਕੀਤਾ, ਜਿਸ ਨੇ 1 ਸਕਿੰਟਾਂ ਵਿੱਚ 47 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਭੇਜੇ
03:38 - ਸਾਰੇ ਨੋਡਸ ਨੇ ਰੂਟ ਚੇਨ ਤੋਂ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜੋ ਬਲਾਕ #85 (f21), #86(65e), #87(256) ਨੂੰ ਜੋੜਿਆ ਗਿਆ ਸੀ ਅਤੇ 330k, 250k, 111855 ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਸੀ।
03:49 - ਪੂਲ ਨੂੰ 330k, 250k, 111855 ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ 'ਤੇ ਕਲੀਅਰ ਕੀਤਾ ਗਿਆ ਸੀ ਜੋ ਬਲਾਕ #85 (f21), #86(65e), #87(256) ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਨ।
03:59 — ਸਬਮਿਟ ਨੋਡ #1 ਨੇ ਪੂਲ ਤੋਂ 888145 ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਕੀਤੇ ਅਤੇ ਬਲਾਕ #88 (214) ਨੂੰ ਫਾਰਮ ਦਿੱਤਾ, ਸਪੁਰਦ ਕਰੋ ਨੋਡ #2 ਨੇ ਪੂਲ ਤੋਂ 750k ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਏ ਅਤੇ ਬਲਾਕ #88 (50a) ਨੂੰ ਫਾਰਮ ਦਿੱਤਾ, ਨੋਡ #3 ਨੇ 670k ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਕੀਤੇ। ਪੂਲ ਅਤੇ ਫਾਰਮ ਬਲਾਕ #88 (d3b)
04:44 — ਬਲਾਕ #88 (d3b) ਉੱਤੇ ਹਸਤਾਖਰ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਹੋਰ ਨੋਡਸ ਨੂੰ ਭੇਜੇ ਗਏ ਹਨ।
04:58 — ਬਲਾਕ #88 (214) ਤੇ ਹਸਤਾਖਰ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਹੋਰ ਨੋਡਸ ਨੂੰ ਭੇਜੇ ਗਏ ਹਨ।
05:11 — ਬਲਾਕ #88 (50a) ਉੱਤੇ ਹਸਤਾਖਰ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਲਈ ਹੋਰ ਨੋਡਸ ਨੂੰ ਭੇਜੇ ਗਏ ਹਨ।
05:11 — ਬਲਾਕ #85 (d3b) ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਰੂਟ ਚੇਨ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ।
05:36 — ਬਲਾਕ #85 (214) ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਰੂਟ ਚੇਨ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ।
05:43 - ਸਾਰੇ ਨੋਡਸ ਰੂਟ ਚੇਨ ਤੋਂ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਜੋ ਬਲਾਕ #88 (d3b), #89(214) ਨੂੰ ਜੋੜਿਆ ਗਿਆ ਹੈ ਅਤੇ 670k, 750k ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਿਹਾ ਹੈ।
06:50 — ਇੱਕ ਸੰਚਾਰ ਅਸਫਲਤਾ ਦੇ ਕਾਰਨ, ਬਲਾਕ #85 (50a) ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਹੋਇਆ ਸੀ
06:55 — ਸਬਮਿਟ ਨੋਡ #2 ਨੇ ਪੂਲ ਤੋਂ 888145 ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਏ ਅਤੇ ਬਲਾਕ #90 (50a) ਫਾਰਮ
08:14 — ਬਲਾਕ #90 (50a) ਉੱਤੇ ਹਸਤਾਖਰ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਲਈ ਹੋਰ ਨੋਡਸ ਨੂੰ ਭੇਜੇ ਗਏ ਹਨ।
09:04 — ਬਲਾਕ #90 (50a) ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਰੂਟ ਚੇਨ ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ
11:23 - ਸਾਰੇ ਨੋਡਸ ਨੇ ਰੂਟ ਚੇਨ ਤੋਂ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜੋ ਬਲਾਕ #90 (50a) ਨੂੰ ਜੋੜਿਆ ਗਿਆ ਸੀ, ਅਤੇ 888145 ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਉਸੇ ਸਮੇਂ, ਸਰਵਰ #3 ਨੇ ਪਹਿਲਾਂ ਹੀ ਬਲਾਕ #88 (d3b), #89 (214) ਤੋਂ ਲੈਣ-ਦੇਣ ਲਾਗੂ ਕਰ ਦਿੱਤਾ ਹੈ।
12:11 - ਸਾਰੇ ਪੂਲ ਖਾਲੀ ਹਨ
13:41 — ਸਰਵਰ #3 ਦੇ ਸਾਰੇ ਨੋਡਸ ਵਿੱਚ 3 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਅਤੇ ਟੋਕਨ ਹਨ
14:35 — ਸਰਵਰ #1 ਦੇ ਸਾਰੇ ਨੋਡਸ ਵਿੱਚ 3 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਅਤੇ ਟੋਕਨ ਹਨ
19:24 — ਸਰਵਰ #2 ਦੇ ਸਾਰੇ ਨੋਡਸ ਵਿੱਚ 3 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਅਤੇ ਟੋਕਨ ਹਨ

ਰੁਕਾਵਟਾਂ

ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਦੇ ਵਿਕਾਸ ਦੇ ਦੌਰਾਨ, ਸਾਨੂੰ ਹੇਠ ਲਿਖੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸੀਂ ਹੌਲੀ-ਹੌਲੀ ਹੱਲ ਕੀਤਾ ਅਤੇ ਹੱਲ ਕਰ ਰਹੇ ਹਾਂ:

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

2. ਇਹ ਤੁਰੰਤ ਸਪੱਸ਼ਟ ਨਹੀਂ ਸੀ ਕਿ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਲਾਗਤਾਂ ਨੂੰ ਘੱਟ ਕਰਦੇ ਹੋਏ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਲੈਣ-ਦੇਣ ਕਿਵੇਂ ਭੇਜਣੇ ਹਨ।

3. ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਸੀ ਕਿ ਉੱਚ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਅਤੇ ਕਿੱਥੇ ਸਟੋਰ ਕਰਨਾ ਹੈ।

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

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

ਅਸੀਂ ਇਸ ਸਭ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਿਆ?

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

1. ਕਈ NodeJS ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਾਂਚ ਕਰੋ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਖਾਸ ਫੰਕਸ਼ਨ ਕਰਦਾ ਹੈ।

2. ਵਰਕਰ_ਥ੍ਰੈਡਸ ਦੀ ਵਰਤੋਂ ਕਰੋ ਅਤੇ ਕੋਡ ਦੇ ਕੁਝ ਹਿੱਸੇ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਥਰਿੱਡਾਂ ਵਿੱਚ ਭੇਜੋ।

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਇੱਕੋ ਸਮੇਂ ਦੋਵਾਂ ਵਿਕਲਪਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ: ਅਸੀਂ ਤਰਕ ਨਾਲ ਇੱਕ ਨੋਡ ਨੂੰ 3 ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਹੈ ਜੋ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਉਸੇ ਸਮੇਂ ਸਮਕਾਲੀ

1. ਸਬਮਿਸ਼ਨ ਨੋਡ, ਜੋ ਪੂਲ ਵਿੱਚ ਲੈਣ-ਦੇਣ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਬਲਾਕ ਬਣਾਉਂਦਾ ਹੈ।

2. ਇੱਕ ਪ੍ਰਮਾਣਿਤ ਨੋਡ ਜੋ ਨੋਡਾਂ ਦੀ ਵੈਧਤਾ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ।

3. API ਨੋਡ - ਡੇਟਾ ਨੂੰ ਐਕਸੈਸ ਕਰਨ ਲਈ ਇੱਕ API ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਸੀਂ cli ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਯੂਨਿਕਸ ਸਾਕਟ ਦੁਆਰਾ ਹਰੇਕ ਨੋਡ ਨਾਲ ਜੁੜ ਸਕਦੇ ਹੋ।

ਅਸੀਂ ਭਾਰੀ ਓਪਰੇਸ਼ਨਾਂ, ਜਿਵੇਂ ਕਿ ਮਾਰਕਲ ਟ੍ਰੀ ਦੀ ਗਣਨਾ, ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਧਾਗੇ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ।

ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਸਾਰੇ ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਫੰਕਸ਼ਨਾਂ ਦਾ ਇੱਕੋ ਸਮੇਂ ਅਤੇ ਬਿਨਾਂ ਅਸਫਲਤਾ ਦੇ ਆਮ ਸੰਚਾਲਨ ਨੂੰ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ।

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

ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਸਿਸਟਮ ਦੀ ਸਿਖਰ ਸਮਰੱਥਾ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਨਾਲ ਸੰਚਾਰ ਦੀ ਵਿਧੀ ਦੀ ਜਾਂਚ ਸ਼ੁਰੂ ਕੀਤੀ। ਅਸੀਂ ਪਹਿਲਾਂ ਲਿਖਿਆ ਸੀ ਕਿ ਪਲਾਜ਼ਮਾ ਕੈਸ਼ ਨੋਡ ਇੱਕ ਯੂਨਿਕਸ ਸਾਕਟ ਇੰਟਰਫੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਪਾਠ-ਅਧਾਰਿਤ ਸੀ। json ਵਸਤੂਆਂ `JSON.parse()` ਅਤੇ `JSON.stringify()` ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਭੇਜੀਆਂ ਗਈਆਂ ਸਨ।

```json
{
  "action": "sendTransaction",
  "payload":{
    "prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
    "prevBlock": 41,
    "tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
    "newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
    "type": "pay",
    "data": "",
    "signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
  }
}
```

ਅਸੀਂ ਅਜਿਹੀਆਂ ਵਸਤੂਆਂ ਦੀ ਟ੍ਰਾਂਸਫਰ ਸਪੀਡ ਨੂੰ ਮਾਪਿਆ ਅਤੇ ~ 130k ਪ੍ਰਤੀ ਸਕਿੰਟ ਪਾਇਆ। ਅਸੀਂ json ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਮਿਆਰੀ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਪਰ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰ ਨਹੀਂ ਹੋਇਆ। V8 ਇੰਜਣ ਨੂੰ ਇਹਨਾਂ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਡਾਟਾਬੇਸ ਵਿੱਚ ਰਿਕਾਰਡਿੰਗ

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

ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਲਈ, ਅਸੀਂ Redis ਨੂੰ ਹੋਰ ਬਾਰੀਕੀ ਨਾਲ ਟਿਊਨ ਕੀਤਾ ਹੈ:

• ਇੱਕ ਯੂਨਿਕਸ ਸਾਕਟ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।
• ਅਸੀਂ ਸਟੇਟ ਨੂੰ ਡਿਸਕ ਵਿੱਚ ਸੇਵ ਕਰਨ ਨੂੰ ਅਸਮਰੱਥ ਕਰ ਦਿੱਤਾ ਹੈ (ਭਰੋਸੇਯੋਗਤਾ ਲਈ, ਤੁਸੀਂ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈਟ ਅਪ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇੱਕ ਵੱਖਰੀ Redis ਵਿੱਚ ਡਿਸਕ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਦੇ ਹੋ)।

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

ਮਿਆਰੀ NodeJS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, Redis ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੇ ਪ੍ਰਤੀ ਸਕਿੰਟ 18k ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਾਪਤ ਕੀਤਾ। ਰਫ਼ਤਾਰ 9 ਵਾਰ ਘਟ ਗਈ।

ਕਿਉਂਕਿ ਬੈਂਚਮਾਰਕ ਨੇ ਸਾਨੂੰ ਦਿਖਾਇਆ ਕਿ ਸੰਭਾਵਨਾਵਾਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ 5 ਗੁਣਾ ਜ਼ਿਆਦਾ ਸਨ, ਅਸੀਂ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਅਸੀਂ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ioredis ਵਿੱਚ ਬਦਲਿਆ ਅਤੇ 25k ਪ੍ਰਤੀ ਸਕਿੰਟ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਪ੍ਰਾਪਤ ਕੀਤੀ। ਅਸੀਂ `hset` ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਲੈਣ-ਦੇਣ ਜੋੜਿਆ ਹੈ। ਇਸ ਲਈ ਅਸੀਂ Redis ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਸਵਾਲ ਪੈਦਾ ਕਰ ਰਹੇ ਸੀ। ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਬੈਚਾਂ ਵਿੱਚ ਜੋੜਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਕਮਾਂਡ `hmset` ਨਾਲ ਭੇਜਣ ਦਾ ਵਿਚਾਰ ਪੈਦਾ ਹੋਇਆ। ਨਤੀਜਾ 32k ਪ੍ਰਤੀ ਸਕਿੰਟ ਹੈ।

ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ, ਜਿਨ੍ਹਾਂ ਦਾ ਅਸੀਂ ਹੇਠਾਂ ਵਰਣਨ ਕਰਾਂਗੇ, ਅਸੀਂ `ਬਫਰ` ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਾਂ ਅਤੇ, ਜਿਵੇਂ ਕਿ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ, ਜੇਕਰ ਤੁਸੀਂ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਟੈਕਸਟ (`buffer.toString('hex')`) ਵਿੱਚ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਵਾਧੂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਪ੍ਰਦਰਸ਼ਨ ਇਸ ਤਰ੍ਹਾਂ, ਸਪੀਡ ਨੂੰ ਵਧਾ ਕੇ 35k ਪ੍ਰਤੀ ਸਕਿੰਟ ਕਰ ਦਿੱਤਾ ਗਿਆ। ਇਸ ਸਮੇਂ, ਅਸੀਂ ਹੋਰ ਅਨੁਕੂਲਤਾ ਨੂੰ ਮੁਅੱਤਲ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

ਸਾਨੂੰ ਇੱਕ ਬਾਈਨਰੀ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਬਦਲਣਾ ਪਿਆ ਕਿਉਂਕਿ:

1. ਸਿਸਟਮ ਅਕਸਰ ਹੈਸ਼ਾਂ, ਦਸਤਖਤਾਂ ਆਦਿ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਲਈ ਇਸਨੂੰ ਬਫਰ ਵਿੱਚ ਡੇਟਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

2. ਜਦੋਂ ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬਾਈਨਰੀ ਡੇਟਾ ਦਾ ਭਾਰ ਟੈਕਸਟ ਨਾਲੋਂ ਘੱਟ ਹੁੰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, 1 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦੇ ਨਾਲ ਇੱਕ ਬਲਾਕ ਭੇਜਣ ਵੇਲੇ, ਟੈਕਸਟ ਵਿੱਚ ਡੇਟਾ 300 ਮੈਗਾਬਾਈਟ ਤੋਂ ਵੱਧ ਲੈ ਸਕਦਾ ਹੈ.

3. ਡਾਟਾ ਨੂੰ ਲਗਾਤਾਰ ਬਦਲਣਾ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

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

ਨਤੀਜੇ ਵਜੋਂ, ਸਾਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਡੇਟਾ ਢਾਂਚੇ ਮਿਲੇ ਹਨ:

- ਲੈਣ-ਦੇਣ

  ```json
  {
    prevHash: BD.types.buffer(20),
    prevBlock: BD.types.uint24le,
    tokenId: BD.types.string(null),
    type: BD.types.uint8,
    newOwner: BD.types.buffer(20),
    dataLength: BD.types.uint24le,
    data: BD.types.buffer(({current}) => current.dataLength),
    signature: BD.types.buffer(65),
    hash: BD.types.buffer(32),
    blockNumber: BD.types.uint24le,
    timestamp: BD.types.uint48le,
  }
  ```

- ਟੋਕਨ

  ```json
  {
    id: BD.types.string(null),
    owner: BD.types.buffer(20),
    block: BD.types.uint24le,
    amount: BD.types.string(null),
  }
  ```

-ਬਲਾਕ

  ```json
  {
    number: BD.types.uint24le,
    merkleRootHash: BD.types.buffer(32),
    signature: BD.types.buffer(65),
    countTx: BD.types.uint24le,
    transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx),
    timestamp: BD.types.uint48le,
  }
  ```

ਆਮ ਕਮਾਂਡਾਂ `BD.encode(block, Protocol).slice();` ਅਤੇ `BD.decode(buffer, Protocol)` ਨਾਲ ਅਸੀਂ ਡਾਟਾ ਨੂੰ Redis ਵਿੱਚ ਸੇਵ ਕਰਨ ਜਾਂ ਕਿਸੇ ਹੋਰ ਨੋਡ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਅਤੇ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ `Buffer` ਵਿੱਚ ਬਦਲਦੇ ਹਾਂ। ਡਾਟਾ ਵਾਪਸ.

ਸਾਡੇ ਕੋਲ ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਲਈ 2 ਬਾਈਨਰੀ ਪ੍ਰੋਟੋਕੋਲ ਵੀ ਹਨ:

- ਯੂਨਿਕਸ ਸਾਕਟ ਦੁਆਰਾ ਪਲਾਜ਼ਮਾ ਨੋਡ ਨਾਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਲਈ ਪ੍ਰੋਟੋਕੋਲ

  ```json
  {
    type: BD.types.uint8,
    messageId: BD.types.uint24le,
    error: BD.types.uint8,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

ਜਿੱਥੇ:

• 'ਕਿਸਮ' — ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਕਾਰਵਾਈ, ਉਦਾਹਰਨ ਲਈ, 1 — sendTransaction, 2 — getTransaction;
• `ਪੇਲੋਡ` - ਡੇਟਾ ਜਿਸ ਨੂੰ ਉਚਿਤ ਫੰਕਸ਼ਨ ਨੂੰ ਪਾਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ;
• 'messageId' - ਸੁਨੇਹਾ ਆਈਡੀ ਤਾਂ ਜੋ ਜਵਾਬ ਦੀ ਪਛਾਣ ਕੀਤੀ ਜਾ ਸਕੇ।

- ਨੋਡਾਂ ਵਿਚਕਾਰ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਲਈ ਪ੍ਰੋਟੋਕੋਲ

  ```json
  {
    code: BD.types.uint8,
    versionProtocol: BD.types.uint24le,
    seq: BD.types.uint8,
    countChunk: BD.types.uint24le,
    chunkNumber: BD.types.uint24le,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

ਜਿੱਥੇ:

• 'ਕੋਡ' — ਸੁਨੇਹਾ ਕੋਡ, ਉਦਾਹਰਨ ਲਈ 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
• `ਵਰਜਨ ਪ੍ਰੋਟੋਕੋਲ` — ਪ੍ਰੋਟੋਕੋਲ ਸੰਸਕਰਣ, ਕਿਉਂਕਿ ਵੱਖ-ਵੱਖ ਸੰਸਕਰਣਾਂ ਵਾਲੇ ਨੋਡਾਂ ਨੂੰ ਨੈੱਟਵਰਕ 'ਤੇ ਉਭਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ;
• `seq` - ਸੁਨੇਹਾ ਪਛਾਣਕਰਤਾ;
• 'countChunk' и `ਚੰਕ ਨੰਬਰ` ਵੱਡੇ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਵੰਡਣ ਲਈ ਜ਼ਰੂਰੀ;
• 'ਲੰਬਾਈ' и `ਪੇਲੋਡ` ਲੰਬਾਈ ਅਤੇ ਡਾਟਾ ਆਪਣੇ ਆਪ.

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

ਜੇ ਅਸੀਂ ਸਪੀਡ 'ਤੇ ਪਹੁੰਚਣ ਵਿਚ ਕਾਮਯਾਬ ਰਹੇ 35 000 ਪ੍ਰਤੀ ਸਕਿੰਟ ਲੈਣ-ਦੇਣ, ਸਾਨੂੰ ਉਹਨਾਂ ਨੂੰ ਅਨੁਕੂਲ ਸਮੇਂ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੀ ਵੀ ਲੋੜ ਹੈ। ਕਿਉਂਕਿ ਲਗਭਗ ਬਲਾਕ ਬਣਾਉਣ ਦਾ ਸਮਾਂ 30 ਸਕਿੰਟ ਲੈਂਦਾ ਹੈ, ਸਾਨੂੰ ਬਲਾਕ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ 1 000 000 ਲੈਣ-ਦੇਣ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਹੋਰ ਭੇਜਣਾ 100 ਡਾਟਾ ਦਾ MB।

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

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

ਸਿੱਟਾ:

ਵਾਸਤਵ ਵਿੱਚ, ਸਾਡੇ ਖੋਜ ਨਵੇਂ ਨਹੀਂ ਹਨ, ਪਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਬਹੁਤ ਸਾਰੇ ਮਾਹਰ ਵਿਕਾਸ ਕਰਨ ਵੇਲੇ ਉਹਨਾਂ ਬਾਰੇ ਭੁੱਲ ਜਾਂਦੇ ਹਨ.

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

ਅਸੀਂ ਤੁਹਾਨੂੰ ਮਿਲਣ ਲਈ ਸੱਦਾ ਦਿੰਦੇ ਹਾਂ GitHub ਪ੍ਰੋਜੈਕਟ: https://github.com/opporty-com/Plasma-Cash/tree/new-version

ਲੇਖ ਦੁਆਰਾ ਸਹਿ-ਲਿਖਿਆ ਗਿਆ ਸੀ ਅਲੈਗਜ਼ੈਂਡਰ ਨਸ਼ੀਵਨ, ਸੀਨੀਅਰ ਡਿਵੈਲਪਰ ਚਲਾਕ ਹੱਲ ਇੰਕ.

ਸਰੋਤ: www.habr.com