ಸಾರ್ವಜನಿಕ ಪರೀಕ್ಷೆ: ಎಥೆರಿಯಮ್‌ನಲ್ಲಿ ಗೌಪ್ಯತೆ ಮತ್ತು ಸ್ಕೇಲೆಬಿಲಿಟಿಗೆ ಪರಿಹಾರ

ಬ್ಲಾಕ್‌ಚೇನ್ ಮಾನವ ಜೀವನದ ಹಲವು ಕ್ಷೇತ್ರಗಳನ್ನು ಸುಧಾರಿಸುವ ಭರವಸೆ ನೀಡುವ ನವೀನ ತಂತ್ರಜ್ಞಾನವಾಗಿದೆ. ಇದು ನೈಜ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಉತ್ಪನ್ನಗಳನ್ನು ಡಿಜಿಟಲ್ ಜಾಗಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತದೆ, ಹಣಕಾಸಿನ ವಹಿವಾಟಿನ ವೇಗ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಅವುಗಳ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ವಿಕೇಂದ್ರೀಕೃತ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಆಧುನಿಕ DAPP ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಬ್ಲಾಕ್‌ಚೈನ್‌ನ ಅನೇಕ ಪ್ರಯೋಜನಗಳು ಮತ್ತು ವೈವಿಧ್ಯಮಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನೀಡಿದರೆ, ಈ ಭರವಸೆಯ ತಂತ್ರಜ್ಞಾನವು ಇನ್ನೂ ಪ್ರತಿಯೊಂದು ಉದ್ಯಮಕ್ಕೂ ತನ್ನ ದಾರಿಯನ್ನು ಮಾಡಿಲ್ಲ ಎಂಬುದು ಆಶ್ಚರ್ಯಕರವಾಗಿ ಕಾಣಿಸಬಹುದು. ಆಧುನಿಕ ವಿಕೇಂದ್ರೀಕೃತ ಬ್ಲಾಕ್‌ಚೈನ್‌ಗಳು ಸ್ಕೇಲೆಬಿಲಿಟಿಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ ಎಂಬುದು ಸಮಸ್ಯೆಯಾಗಿದೆ. Ethereum ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 20 ವಹಿವಾಟುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಇದು ಇಂದಿನ ಡೈನಾಮಿಕ್ ವ್ಯವಹಾರಗಳ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸಲು ಸಾಕಾಗುವುದಿಲ್ಲ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಬ್ಲಾಕ್‌ಚೈನ್ ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸುವ ಕಂಪನಿಗಳು ಹ್ಯಾಕಿಂಗ್ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ವೈಫಲ್ಯಗಳಿಂದ ಹೆಚ್ಚಿನ ಮಟ್ಟದ ರಕ್ಷಣೆಯಿಂದಾಗಿ Ethereum ಅನ್ನು ತ್ಯಜಿಸಲು ಹಿಂಜರಿಯುತ್ತವೆ.

ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿ ವಿಕೇಂದ್ರೀಕರಣ, ಭದ್ರತೆ ಮತ್ತು ಸ್ಕೇಲೆಬಿಲಿಟಿಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಅಭಿವೃದ್ಧಿ ತಂಡವಾದ ಸ್ಕೇಲೆಬಿಲಿಟಿ ಟ್ರೈಲೆಮಾವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಅವಕಾಶ ಪ್ಲಾಸ್ಮಾ ಕ್ಯಾಶ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ, ಇದು ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದವನ್ನು ಒಳಗೊಂಡಿರುವ ಒಂದು ಅಂಗಸಂಸ್ಥೆ ಸರಪಳಿ ಮತ್ತು Node.js ಅನ್ನು ಆಧರಿಸಿದ ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ರೂಟ್ ಚೈನ್‌ಗೆ (Ethereum) ವರ್ಗಾಯಿಸುತ್ತದೆ.

ಪ್ಲಾಸ್ಮಾ ನಗದು ಪ್ರಮುಖ ಪ್ರಕ್ರಿಯೆಗಳು

1. ಬಳಕೆದಾರರು ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದದ ಕಾರ್ಯವನ್ನು `ಠೇವಣಿ~ ಎಂದು ಕರೆಯುತ್ತಾರೆ, ಅವರು ಪ್ಲಾಸ್ಮಾ ನಗದು ಟೋಕನ್‌ಗೆ ಠೇವಣಿ ಮಾಡಲು ಬಯಸುವ ETH ಮೊತ್ತವನ್ನು ಅದರೊಳಗೆ ರವಾನಿಸುತ್ತಾರೆ. ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದದ ಕಾರ್ಯವು ಟೋಕನ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಈವೆಂಟ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ.

2. ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದದ ಈವೆಂಟ್‌ಗಳಿಗೆ ಚಂದಾದಾರರಾಗಿರುವ ಪ್ಲಾಸ್ಮಾ ನಗದು ನೋಡ್‌ಗಳು ಠೇವಣಿ ರಚಿಸುವ ಕುರಿತು ಈವೆಂಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ ಮತ್ತು ಪೂಲ್‌ಗೆ ಟೋಕನ್ ರಚಿಸುವ ಕುರಿತು ವಹಿವಾಟನ್ನು ಸೇರಿಸುತ್ತವೆ.

3. ನಿಯತಕಾಲಿಕವಾಗಿ, ವಿಶೇಷ ಪ್ಲಾಸ್ಮಾ ನಗದು ನೋಡ್‌ಗಳು ಎಲ್ಲಾ ವಹಿವಾಟುಗಳನ್ನು ಪೂಲ್‌ನಿಂದ (1 ಮಿಲಿಯನ್ ವರೆಗೆ) ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಅವುಗಳಿಂದ ಒಂದು ಬ್ಲಾಕ್ ಅನ್ನು ರೂಪಿಸುತ್ತವೆ, ಮೆರ್ಕಲ್ ಟ್ರೀ ಅನ್ನು ಲೆಕ್ಕಹಾಕಿ ಮತ್ತು ಅದರ ಪ್ರಕಾರ ಹ್ಯಾಶ್. ಈ ಬ್ಲಾಕ್ ಅನ್ನು ಪರಿಶೀಲನೆಗಾಗಿ ಇತರ ನೋಡ್‌ಗಳಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ನೋಡ್‌ಗಳು ಮರ್ಕೆಲ್ ಹ್ಯಾಶ್ ಮಾನ್ಯವಾಗಿದೆಯೇ ಮತ್ತು ವಹಿವಾಟುಗಳು ಮಾನ್ಯವಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಟೋಕನ್ ಕಳುಹಿಸುವವರು ಅದರ ಮಾಲೀಕರೇ). ಬ್ಲಾಕ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿದ ನಂತರ, ನೋಡ್ ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದದ `ಸಬ್ಮಿಟ್ಬ್ಲಾಕ್' ಕಾರ್ಯವನ್ನು ಕರೆಯುತ್ತದೆ, ಇದು ಬ್ಲಾಕ್ ಸಂಖ್ಯೆ ಮತ್ತು ಮರ್ಕಲ್ ಹ್ಯಾಶ್ ಅನ್ನು ಅಂಚಿನ ಸರಪಳಿಗೆ ಉಳಿಸುತ್ತದೆ. ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದವು ಬ್ಲಾಕ್ನ ಯಶಸ್ವಿ ಸೇರ್ಪಡೆಯನ್ನು ಸೂಚಿಸುವ ಈವೆಂಟ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಪೂಲ್‌ನಿಂದ ವಹಿವಾಟುಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.

4. ಬ್ಲಾಕ್ ಸಲ್ಲಿಕೆ ಈವೆಂಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವ ನೋಡ್‌ಗಳು ಬ್ಲಾಕ್‌ಗೆ ಸೇರಿಸಲಾದ ವಹಿವಾಟುಗಳನ್ನು ಅನ್ವಯಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ.

5. ಕೆಲವು ಹಂತದಲ್ಲಿ, ಟೋಕನ್‌ನ ಮಾಲೀಕರು (ಅಥವಾ ಮಾಲೀಕರಲ್ಲದವರು) ಅದನ್ನು ಪ್ಲಾಸ್ಮಾ ಕ್ಯಾಶ್‌ನಿಂದ ಹಿಂಪಡೆಯಲು ಬಯಸುತ್ತಾರೆ. ಇದನ್ನು ಮಾಡಲು, ಅವರು ಟೋಕನ್‌ನಲ್ಲಿನ ಕೊನೆಯ 2 ವಹಿವಾಟುಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ರವಾನಿಸುವ `ಸ್ಟಾರ್ಟ್‌ಎಕ್ಸಿಟ್` ಕಾರ್ಯವನ್ನು ಕರೆಯುತ್ತಾರೆ, ಅದು ಅವರು ಟೋಕನ್‌ನ ಮಾಲೀಕರೆಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದ, ಮರ್ಕೆಲ್ ಹ್ಯಾಶ್ ಅನ್ನು ಬಳಸಿ, ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ವಹಿವಾಟುಗಳ ಉಪಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ವಾಪಸಾತಿಗಾಗಿ ಟೋಕನ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಇದು ಎರಡು ವಾರಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ.

6. ಟೋಕನ್ ವಾಪಸಾತಿ ಕಾರ್ಯಾಚರಣೆಯು ಉಲ್ಲಂಘನೆಯೊಂದಿಗೆ ಸಂಭವಿಸಿದಲ್ಲಿ (ಹಿಂತೆಗೆದುಕೊಳ್ಳುವ ಪ್ರಕ್ರಿಯೆಯು ಪ್ರಾರಂಭವಾದ ನಂತರ ಟೋಕನ್ ಅನ್ನು ಖರ್ಚು ಮಾಡಲಾಗಿದೆ ಅಥವಾ ವಾಪಸಾತಿಗೆ ಮುಂಚಿತವಾಗಿ ಟೋಕನ್ ಬೇರೊಬ್ಬರದ್ದಾಗಿತ್ತು), ಟೋಕನ್ ಮಾಲೀಕರು ಎರಡು ವಾರಗಳಲ್ಲಿ ವಾಪಸಾತಿಯನ್ನು ನಿರಾಕರಿಸಬಹುದು.

ಗೌಪ್ಯತೆಯನ್ನು ಎರಡು ರೀತಿಯಲ್ಲಿ ಸಾಧಿಸಲಾಗುತ್ತದೆ

1. ಚೈಲ್ಡ್ ಚೈನ್‌ನಲ್ಲಿ ಉತ್ಪತ್ತಿಯಾಗುವ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ವಹಿವಾಟಿನ ಬಗ್ಗೆ ರೂಟ್ ಚೈನ್‌ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ. ಪ್ಲಾಸ್ಮಾ ಕ್ಯಾಶ್‌ನಿಂದ ETH ಅನ್ನು ಯಾರು ಠೇವಣಿ ಮಾಡಿದರು ಮತ್ತು ಹಿಂತೆಗೆದುಕೊಂಡರು ಎಂಬ ಮಾಹಿತಿಯು ಸಾರ್ವಜನಿಕವಾಗಿ ಉಳಿದಿದೆ.

2. ಚೈಲ್ಡ್ ಚೈನ್ zk-SNARK ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅನಾಮಧೇಯ ವಹಿವಾಟುಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ತಂತ್ರಜ್ಞಾನ ಸ್ಟಾಕ್

• ನೋಡ್ಜೆಎಸ್
• ಕೆಂಪು
• ಎಥೆರಿಯಮ್
• ಮಣ್ಣು

ಪರೀಕ್ಷೆ

ಪ್ಲಾಸ್ಮಾ ಕ್ಯಾಶ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ, ನಾವು ಸಿಸ್ಟಮ್‌ನ ವೇಗವನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ ಮತ್ತು ಈ ಕೆಳಗಿನ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ:

• ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 35 ವಹಿವಾಟುಗಳನ್ನು ಪೂಲ್‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ;
• ಒಂದು ಬ್ಲಾಕ್‌ನಲ್ಲಿ 1 ವಹಿವಾಟುಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು.

ಕೆಳಗಿನ 3 ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲಾಯಿತು:

1. ಇಂಟೆಲ್ ಕೋರ್ i7-6700 ಕ್ವಾಡ್-ಕೋರ್ ಸ್ಕೈಲೇಕ್ incl. NVMe SSD - 512 GB, 64 GB DDR4 RAM
3 ಮೌಲ್ಯೀಕರಿಸುವ ಪ್ಲಾಸ್ಮಾ ನಗದು ನೋಡ್‌ಗಳನ್ನು ಹೆಚ್ಚಿಸಲಾಗಿದೆ.

2. AMD Ryzen 7 1700X ಆಕ್ಟಾ-ಕೋರ್ "ಸಮ್ಮಿಟ್ ರಿಡ್ಜ್" (ಝೆನ್), SATA SSD - 500 GB, 64 GB DDR4 RAM
Ropsten testnet ETH ನೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸಲಾಗಿದೆ.
3 ಮೌಲ್ಯೀಕರಿಸುವ ಪ್ಲಾಸ್ಮಾ ನಗದು ನೋಡ್‌ಗಳನ್ನು ಹೆಚ್ಚಿಸಲಾಗಿದೆ.

3. ಇಂಟೆಲ್ ಕೋರ್ i9-9900K ಆಕ್ಟಾ-ಕೋರ್ incl. NVMe SSD - 1 TB, 64 GB DDR4 RAM
1 ಪ್ಲಾಸ್ಮಾ ನಗದು ಸಲ್ಲಿಕೆ ನೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸಲಾಗಿದೆ.
3 ಮೌಲ್ಯೀಕರಿಸುವ ಪ್ಲಾಸ್ಮಾ ನಗದು ನೋಡ್‌ಗಳನ್ನು ಹೆಚ್ಚಿಸಲಾಗಿದೆ.
ಪ್ಲಾಸ್ಮಾ ನಗದು ನೆಟ್‌ವರ್ಕ್‌ಗೆ ವಹಿವಾಟುಗಳನ್ನು ಸೇರಿಸಲು ಪರೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ.

ಒಟ್ಟು: ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ 10 ಪ್ಲಾಸ್ಮಾ ನಗದು ನೋಡ್‌ಗಳು.

ಪರೀಕ್ಷೆ 1

ಪ್ರತಿ ಬ್ಲಾಕ್‌ಗೆ 1 ಮಿಲಿಯನ್ ವಹಿವಾಟುಗಳ ಮಿತಿ ಇದೆ. ಆದ್ದರಿಂದ, 1 ಮಿಲಿಯನ್ ವಹಿವಾಟುಗಳು 2 ಬ್ಲಾಕ್‌ಗಳಾಗಿ ಬೀಳುತ್ತವೆ (ಸಿಸ್ಟಮ್ ವಹಿವಾಟುಗಳ ಭಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಮತ್ತು ಅವುಗಳನ್ನು ಕಳುಹಿಸುವಾಗ ಸಲ್ಲಿಸಲು ನಿರ್ವಹಿಸುತ್ತದೆ).

ಆರಂಭಿಕ ಸ್ಥಿತಿ: ಕೊನೆಯ ಬ್ಲಾಕ್ #7; 1 ಮಿಲಿಯನ್ ವಹಿವಾಟುಗಳು ಮತ್ತು ಟೋಕನ್‌ಗಳನ್ನು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.

00:00 — ವಹಿವಾಟು ಉತ್ಪಾದನೆಯ ಸ್ಕ್ರಿಪ್ಟ್ ಪ್ರಾರಂಭ
01:37 - 1 ಮಿಲಿಯನ್ ವಹಿವಾಟುಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ನೋಡ್‌ಗೆ ಕಳುಹಿಸುವುದು ಪ್ರಾರಂಭವಾಯಿತು
01:46 — ಸಬ್‌ಮಿಟ್ ನೋಡ್ ಪೂಲ್‌ನಿಂದ 240k ವಹಿವಾಟುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ಫಾರ್ಮ್ಸ್ ಬ್ಲಾಕ್ #8. 320 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 10k ವಹಿವಾಟುಗಳನ್ನು ಪೂಲ್‌ಗೆ ಸೇರಿಸುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ
01:58 — ಬ್ಲಾಕ್ #8 ಅನ್ನು ಸಹಿ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಮೌಲ್ಯೀಕರಣಕ್ಕಾಗಿ ಕಳುಹಿಸಲಾಗಿದೆ
02:03 — ಬ್ಲಾಕ್ #8 ಅನ್ನು ಮೌಲ್ಯೀಕರಿಸಲಾಗಿದೆ ಮತ್ತು ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದದ `ಸಬ್ಮಿಟ್ಬ್ಲಾಕ್' ಕಾರ್ಯವನ್ನು ಮರ್ಕಲ್ ಹ್ಯಾಶ್ ಮತ್ತು ಬ್ಲಾಕ್ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಕರೆಯಲಾಗುತ್ತದೆ.
02:10 — ಡೆಮೊ ಸ್ಕ್ರಿಪ್ಟ್ ಕೆಲಸ ಮುಗಿದಿದೆ, ಇದು 1 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 32 ಮಿಲಿಯನ್ ವಹಿವಾಟುಗಳನ್ನು ಕಳುಹಿಸಿದೆ
02:33 - ಬ್ಲಾಕ್ #8 ಅನ್ನು ರೂಟ್ ಚೈನ್‌ಗೆ ಸೇರಿಸಲಾಗಿದೆ ಮತ್ತು 240k ವಹಿವಾಟುಗಳನ್ನು ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು ಎಂಬ ಮಾಹಿತಿಯನ್ನು ನೋಡ್‌ಗಳು ಸ್ವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು.
02:40 - 240k ವಹಿವಾಟುಗಳನ್ನು ಪೂಲ್‌ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ, ಅವುಗಳು ಈಗಾಗಲೇ #8 ಬ್ಲಾಕ್‌ನಲ್ಲಿವೆ
02:56 — ಸಬ್ಮಿಟ್ ನೋಡ್ ಪೂಲ್‌ನಿಂದ ಉಳಿದ 760k ವಹಿವಾಟುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ಮರ್ಕಲ್ ಹ್ಯಾಶ್ ಮತ್ತು ಸಹಿ ಬ್ಲಾಕ್ ಅನ್ನು ಲೆಕ್ಕಹಾಕಲು ಪ್ರಾರಂಭಿಸಿತು #9
03:20 - ಎಲ್ಲಾ ನೋಡ್‌ಗಳು 1 ಮಿಲಿಯನ್ 240k ವಹಿವಾಟುಗಳು ಮತ್ತು ಟೋಕನ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ
03:35 — ಬ್ಲಾಕ್ #9 ಅನ್ನು ಸಹಿ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಇತರ ನೋಡ್‌ಗಳಿಗೆ ಮೌಲ್ಯೀಕರಣಕ್ಕಾಗಿ ಕಳುಹಿಸಲಾಗಿದೆ
03:41 - ನೆಟ್‌ವರ್ಕ್ ದೋಷ ಸಂಭವಿಸಿದೆ
04:40 — ಬ್ಲಾಕ್ #9 ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆಗಾಗಿ ಕಾಯುವ ಸಮಯ ಮೀರಿದೆ
04:54 — ಸಬ್ಮಿಟ್ ನೋಡ್ ಪೂಲ್‌ನಿಂದ ಉಳಿದ 760k ವಹಿವಾಟುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ಮರ್ಕಲ್ ಹ್ಯಾಶ್ ಮತ್ತು ಸಹಿ ಬ್ಲಾಕ್ ಅನ್ನು ಲೆಕ್ಕಹಾಕಲು ಪ್ರಾರಂಭಿಸಿತು #9
05:32 — ಬ್ಲಾಕ್ #9 ಅನ್ನು ಸಹಿ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಇತರ ನೋಡ್‌ಗಳಿಗೆ ಮೌಲ್ಯೀಕರಣಕ್ಕಾಗಿ ಕಳುಹಿಸಲಾಗಿದೆ
05:53 — ಬ್ಲಾಕ್ #9 ಅನ್ನು ಮೌಲ್ಯೀಕರಿಸಲಾಗಿದೆ ಮತ್ತು ರೂಟ್ ಚೈನ್‌ಗೆ ಕಳುಹಿಸಲಾಗಿದೆ
06:17 - ಬ್ಲಾಕ್ #9 ಅನ್ನು ರೂಟ್ ಚೈನ್‌ಗೆ ಸೇರಿಸಲಾಗಿದೆ ಮತ್ತು 760k ವಹಿವಾಟುಗಳನ್ನು ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು ಎಂಬ ಮಾಹಿತಿಯನ್ನು ನೋಡ್‌ಗಳು ಸ್ವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು.
06:47 — ಬ್ಲಾಕ್ #9 ರಲ್ಲಿನ ವಹಿವಾಟುಗಳನ್ನು ಪೂಲ್ ತೆರವುಗೊಳಿಸಿದೆ
09:06 - ಎಲ್ಲಾ ನೋಡ್‌ಗಳು 2 ಮಿಲಿಯನ್ ವಹಿವಾಟುಗಳು ಮತ್ತು ಟೋಕನ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ

ಪರೀಕ್ಷೆ 2

ಪ್ರತಿ ಬ್ಲಾಕ್‌ಗೆ 350ಕೆ ಮಿತಿ ಇದೆ. ಪರಿಣಾಮವಾಗಿ, ನಾವು 3 ಬ್ಲಾಕ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಆರಂಭಿಕ ಸ್ಥಿತಿ: ಕೊನೆಯ ಬ್ಲಾಕ್ #9; ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ 2 ಮಿಲಿಯನ್ ವಹಿವಾಟುಗಳು ಮತ್ತು ಟೋಕನ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ

00:00 — ವಹಿವಾಟು ಉತ್ಪಾದನೆಯ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಈಗಾಗಲೇ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ
00:44 - 1 ಮಿಲಿಯನ್ ವಹಿವಾಟುಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ನೋಡ್‌ಗೆ ಕಳುಹಿಸುವುದು ಪ್ರಾರಂಭವಾಯಿತು
00:56 — ಸಬ್‌ಮಿಟ್ ನೋಡ್ ಪೂಲ್‌ನಿಂದ 320k ವಹಿವಾಟುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ಫಾರ್ಮ್ಸ್ ಬ್ಲಾಕ್ #10. 320 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 10k ವಹಿವಾಟುಗಳನ್ನು ಪೂಲ್‌ಗೆ ಸೇರಿಸುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ
01:12 — ಬ್ಲಾಕ್ #10 ಅನ್ನು ಸಹಿ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಮೌಲ್ಯೀಕರಣಕ್ಕಾಗಿ ಇತರ ನೋಡ್‌ಗಳಿಗೆ ಕಳುಹಿಸಲಾಗಿದೆ
01:18 — ಡೆಮೊ ಸ್ಕ್ರಿಪ್ಟ್ ಕೆಲಸ ಮುಗಿದಿದೆ, ಇದು 1 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 34 ಮಿಲಿಯನ್ ವಹಿವಾಟುಗಳನ್ನು ಕಳುಹಿಸಿದೆ
01:20 — ಬ್ಲಾಕ್ #10 ಅನ್ನು ಮೌಲ್ಯೀಕರಿಸಲಾಗಿದೆ ಮತ್ತು ರೂಟ್ ಚೈನ್‌ಗೆ ಕಳುಹಿಸಲಾಗಿದೆ
01:51 - ಬ್ಲಾಕ್ #10 ಅನ್ನು ಸೇರಿಸಲಾಗಿದೆ ಮತ್ತು 320k ವಹಿವಾಟುಗಳನ್ನು ಅನ್ವಯಿಸಲು ಪ್ರಾರಂಭಿಸಿದ ರೂಟ್ ಚೈನ್‌ನಿಂದ ಎಲ್ಲಾ ನೋಡ್‌ಗಳು ಮಾಹಿತಿಯನ್ನು ಪಡೆದುಕೊಂಡವು
02:01 - ಬ್ಲಾಕ್ #320 ಗೆ ಸೇರಿಸಲಾದ 10k ವಹಿವಾಟುಗಳಿಗೆ ಪೂಲ್ ತೆರವುಗೊಳಿಸಲಾಗಿದೆ
02:15 — ಸಬ್‌ಮಿಟ್ ನೋಡ್ ಪೂಲ್‌ನಿಂದ 350k ವಹಿವಾಟುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ಫಾರ್ಮ್‌ಗಳ ಬ್ಲಾಕ್ #11
02:34 — ಬ್ಲಾಕ್ #11 ಅನ್ನು ಸಹಿ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಮೌಲ್ಯೀಕರಣಕ್ಕಾಗಿ ಇತರ ನೋಡ್‌ಗಳಿಗೆ ಕಳುಹಿಸಲಾಗಿದೆ
02:51 — ಬ್ಲಾಕ್ #11 ಅನ್ನು ಮೌಲ್ಯೀಕರಿಸಲಾಗಿದೆ ಮತ್ತು ರೂಟ್ ಚೈನ್‌ಗೆ ಕಳುಹಿಸಲಾಗಿದೆ
02:55 — ಕೊನೆಯ ನೋಡ್ ಬ್ಲಾಕ್ #10 ರಿಂದ ವಹಿವಾಟುಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಿತು
10:59 — ಬ್ಲಾಕ್ #9 ಸಲ್ಲಿಕೆಯೊಂದಿಗೆ ವ್ಯವಹಾರವು ರೂಟ್ ಚೈನ್‌ನಲ್ಲಿ ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು, ಆದರೆ ಅದು ಪೂರ್ಣಗೊಂಡಿತು ಮತ್ತು ಎಲ್ಲಾ ನೋಡ್‌ಗಳು ಅದರ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪಡೆದುಕೊಂಡವು ಮತ್ತು 350k ವಹಿವಾಟುಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು.
11:05 - ಬ್ಲಾಕ್ #320 ಗೆ ಸೇರಿಸಲಾದ 11k ವಹಿವಾಟುಗಳಿಗೆ ಪೂಲ್ ತೆರವುಗೊಳಿಸಲಾಗಿದೆ
12:10 - ಎಲ್ಲಾ ನೋಡ್‌ಗಳು 1 ಮಿಲಿಯನ್ 670k ವಹಿವಾಟುಗಳು ಮತ್ತು ಟೋಕನ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ
12:17 — ಸಬ್ಮಿಟ್ ನೋಡ್ ಪೂಲ್‌ನಿಂದ 330k ವಹಿವಾಟುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ಫಾರ್ಮ್‌ಗಳ ಬ್ಲಾಕ್ #12
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 ಪೂಲ್‌ನಿಂದ 330k ವಹಿವಾಟುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ಫಾರ್ಮ್‌ಗಳ ಬ್ಲಾಕ್ #85 (f21). 350 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 10k ವಹಿವಾಟುಗಳನ್ನು ಪೂಲ್‌ಗೆ ಸೇರಿಸುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ
01:53 — 1 ಮಿಲಿಯನ್ ವಹಿವಾಟುಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ನೋಡ್ #1 ಅನ್ನು ಸಲ್ಲಿಸಲು ಕಳುಹಿಸುವುದು ಪ್ರಾರಂಭವಾಯಿತು
01:50 — ಸಬ್‌ಮಿಟ್ ನೋಡ್ #3 ಪೂಲ್‌ನಿಂದ 330k ವಹಿವಾಟುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ಫಾರ್ಮ್‌ಗಳ ಬ್ಲಾಕ್ #85 (f21). 350 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 10k ವಹಿವಾಟುಗಳನ್ನು ಪೂಲ್‌ಗೆ ಸೇರಿಸುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ
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 - #330 (f250), #111855(85e), #21(86) ಬ್ಲಾಕ್‌ಗಳಿಗೆ ಸೇರಿಸಲಾದ 65k, 87k, 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 (d88b), #3(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 ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಕ್ಲಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಯುನಿಕ್ಸ್ ಸಾಕೆಟ್ ಮೂಲಕ ಪ್ರತಿ ನೋಡ್‌ಗೆ ಸಂಪರ್ಕಿಸಬಹುದು.

ನಾವು ಮರ್ಕಲ್ ಮರವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವಂತಹ ಭಾರೀ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಥ್ರೆಡ್‌ಗೆ ಸ್ಥಳಾಂತರಿಸಿದ್ದೇವೆ.

ಹೀಗಾಗಿ, ನಾವು ಎಲ್ಲಾ ಪ್ಲಾಸ್ಮಾ ನಗದು ಕಾರ್ಯಗಳ ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಮತ್ತು ವೈಫಲ್ಯಗಳಿಲ್ಲದೆ ಸಾಧಿಸಿದ್ದೇವೆ.

ಒಮ್ಮೆ ಸಿಸ್ಟಮ್ ಕ್ರಿಯಾತ್ಮಕವಾದಾಗ, ನಾವು ವೇಗವನ್ನು ಪರೀಕ್ಷಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ದುರದೃಷ್ಟವಶಾತ್, ಅತೃಪ್ತಿಕರ ಫಲಿತಾಂಶಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ: ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 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 ಪಟ್ಟು ಕಡಿಮೆಯಾಗಿದೆ, ಇದು OOP ನಮಗೆ ಸೂಕ್ತವಲ್ಲ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ನಾನು ಎಲ್ಲವನ್ನೂ ಸಂಪೂರ್ಣವಾಗಿ ಕ್ರಿಯಾತ್ಮಕ ವಿಧಾನಕ್ಕೆ ಪುನಃ ಬರೆಯಬೇಕಾಗಿತ್ತು.

ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ರೆಕಾರ್ಡಿಂಗ್

ಆರಂಭದಲ್ಲಿ, ನಮ್ಮ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುವ ಅತ್ಯಂತ ಉತ್ಪಾದಕ ಪರಿಹಾರಗಳಲ್ಲಿ ಒಂದಾಗಿ ಡೇಟಾ ಸಂಗ್ರಹಣೆಗಾಗಿ Redis ಅನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ: ಕೀ-ಮೌಲ್ಯ ಸಂಗ್ರಹಣೆ, ಹ್ಯಾಶ್ ಕೋಷ್ಟಕಗಳು, ಸೆಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು. ನಾವು redis-benchmark ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು 80 ಪೈಪ್‌ಲೈನಿಂಗ್ ಮೋಡ್‌ನಲ್ಲಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ~1k ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ.

ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ, ನಾವು ರೆಡಿಸ್ ಅನ್ನು ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮವಾಗಿ ಟ್ಯೂನ್ ಮಾಡಿದ್ದೇವೆ:

• ಯುನಿಕ್ಸ್ ಸಾಕೆಟ್ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ.
• ಡಿಸ್ಕ್ಗೆ ರಾಜ್ಯವನ್ನು ಉಳಿಸುವುದನ್ನು ನಾವು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ್ದೇವೆ (ವಿಶ್ವಾಸಾರ್ಹತೆಗಾಗಿ, ನೀವು ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿಸಬಹುದು ಮತ್ತು ಪ್ರತ್ಯೇಕ ರೆಡಿಸ್ನಲ್ಲಿ ಡಿಸ್ಕ್ಗೆ ಉಳಿಸಬಹುದು).

ರೆಡಿಸ್‌ನಲ್ಲಿ, ಪೂಲ್ ಹ್ಯಾಶ್ ಟೇಬಲ್ ಆಗಿದೆ ಏಕೆಂದರೆ ನಾವು ಎಲ್ಲಾ ವಹಿವಾಟುಗಳನ್ನು ಒಂದೇ ಪ್ರಶ್ನೆಯಲ್ಲಿ ಹಿಂಪಡೆಯಲು ಮತ್ತು ವಹಿವಾಟುಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಅಳಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ನಾವು ಸಾಮಾನ್ಯ ಪಟ್ಟಿಯನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ, ಆದರೆ ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯನ್ನು ಇಳಿಸುವಾಗ ಅದು ನಿಧಾನವಾಗಿರುತ್ತದೆ.

ಪ್ರಮಾಣಿತ NodeJS ಅನ್ನು ಬಳಸುವಾಗ, ರೆಡಿಸ್ ಲೈಬ್ರರಿಗಳು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 18k ವಹಿವಾಟುಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸಿದವು. ವೇಗವು 9 ಬಾರಿ ಕುಸಿಯಿತು.

ಮಾನದಂಡವು ನಮಗೆ ಸಾಧ್ಯತೆಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ 5 ಪಟ್ಟು ಹೆಚ್ಚು ತೋರಿಸಿದ್ದರಿಂದ, ನಾವು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ನಾವು ಲೈಬ್ರರಿಯನ್ನು ioredis ಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ ಮತ್ತು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 25k ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. ನಾವು `hset` ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಒಂದೊಂದಾಗಿ ವಹಿವಾಟುಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ಆದ್ದರಿಂದ ನಾವು Redis ನಲ್ಲಿ ಬಹಳಷ್ಟು ಪ್ರಶ್ನೆಗಳನ್ನು ರಚಿಸುತ್ತಿದ್ದೇವೆ. ವಹಿವಾಟುಗಳನ್ನು ಬ್ಯಾಚ್‌ಗಳಾಗಿ ಸಂಯೋಜಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು `hmset` ಎಂಬ ಒಂದು ಆಜ್ಞೆಯೊಂದಿಗೆ ಕಳುಹಿಸುವ ಆಲೋಚನೆ ಹುಟ್ಟಿಕೊಂಡಿತು. ಫಲಿತಾಂಶವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 32 ಕೆ.

ಹಲವಾರು ಕಾರಣಗಳಿಗಾಗಿ, ನಾವು ಕೆಳಗೆ ವಿವರಿಸುವ, ನಾವು `ಬಫರ್` ಅನ್ನು ಬಳಸಿಕೊಂಡು ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ನೀವು ಅದನ್ನು ಬರೆಯುವ ಮೊದಲು ಪಠ್ಯಕ್ಕೆ (`buffer.toString('hex')`) ಪರಿವರ್ತಿಸಿದರೆ, ನೀವು ಹೆಚ್ಚುವರಿ ಪಡೆಯಬಹುದು ಪ್ರದರ್ಶನ. ಹೀಗಾಗಿ, ವೇಗವನ್ನು ಸೆಕೆಂಡಿಗೆ 35 ಕೆ. ಈ ಸಮಯದಲ್ಲಿ, ನಾವು ಮತ್ತಷ್ಟು ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಅಮಾನತುಗೊಳಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ನಾವು ಬೈನರಿ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಬದಲಾಯಿಸಬೇಕಾಗಿತ್ತು ಏಕೆಂದರೆ:

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)` ಮೂಲಕ ನಾವು ಡೇಟಾವನ್ನು ರೆಡಿಸ್‌ನಲ್ಲಿ ಉಳಿಸಲು ಅಥವಾ ಇನ್ನೊಂದು ನೋಡ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಮತ್ತು ಹಿಂಪಡೆಯಲು ಡೇಟಾವನ್ನು `ಬಫರ್` ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತೇವೆ ಡೇಟಾ ಹಿಂತಿರುಗಿ.

ಸೇವೆಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲು ನಾವು 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;
• `ಪೇಲೋಡ್` - ಸೂಕ್ತವಾದ ಕಾರ್ಯಕ್ಕೆ ರವಾನಿಸಬೇಕಾದ ಡೇಟಾ;
• `ಸಂದೇಶ ಐಡಿ` - ಸಂದೇಶ ಐಡಿ ಇದರಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಗುರುತಿಸಬಹುದು.

- ನೋಡ್ಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಗಾಗಿ ಪ್ರೋಟೋಕಾಲ್

  ```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` - ಸಂದೇಶ ಗುರುತಿಸುವಿಕೆ;
• `ಕೌಂಟ್ ಚಂಕ್` и `ಚಂಕ್ ಸಂಖ್ಯೆ` ದೊಡ್ಡ ಸಂದೇಶಗಳನ್ನು ವಿಭಜಿಸಲು ಅವಶ್ಯಕ;
• `ಉದ್ದ` и `ಪೇಲೋಡ್` ಉದ್ದ ಮತ್ತು ಡೇಟಾ ಸ್ವತಃ.

ನಾವು ಡೇಟಾವನ್ನು ಮೊದಲೇ ಟೈಪ್ ಮಾಡಿರುವುದರಿಂದ, ಅಂತಿಮ ವ್ಯವಸ್ಥೆಯು Ethereum ನ `rlp` ಲೈಬ್ರರಿಗಿಂತ ಹೆಚ್ಚು ವೇಗವಾಗಿರುತ್ತದೆ. ದುರದೃಷ್ಟವಶಾತ್, ನಾವು ಅದನ್ನು ನಿರಾಕರಿಸಲು ಇನ್ನೂ ಸಾಧ್ಯವಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಭವಿಷ್ಯದಲ್ಲಿ ನಾವು ಮಾಡಲು ಯೋಜಿಸಿರುವ ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದವನ್ನು ಅಂತಿಮಗೊಳಿಸುವುದು ಅವಶ್ಯಕ.

ನಾವು ವೇಗವನ್ನು ತಲುಪಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ 35 000 ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಹಿವಾಟುಗಳು, ನಾವು ಅವುಗಳನ್ನು ಸೂಕ್ತ ಸಮಯದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾಗಿದೆ. ಅಂದಾಜು ಬ್ಲಾಕ್ ರಚನೆಯ ಸಮಯವು 30 ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದರಿಂದ, ನಾವು ಬ್ಲಾಕ್ನಲ್ಲಿ ಸೇರಿಸಬೇಕಾಗಿದೆ 1 000 000 ವಹಿವಾಟುಗಳು, ಅಂದರೆ ಹೆಚ್ಚಿನದನ್ನು ಕಳುಹಿಸುವುದು 100 MB ಡೇಟಾ.

ಆರಂಭದಲ್ಲಿ, ನೋಡ್‌ಗಳ ನಡುವೆ ಸಂವಹನ ನಡೆಸಲು ನಾವು `ethereumjs-devp2p` ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿದ್ದೇವೆ, ಆದರೆ ಅದು ಹೆಚ್ಚಿನ ಡೇಟಾವನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ನಾವು `ws` ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿದ್ದೇವೆ ಮತ್ತು ವೆಬ್‌ಸಾಕೆಟ್ ಮೂಲಕ ಬೈನರಿ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೇವೆ. ಸಹಜವಾಗಿ, ದೊಡ್ಡ ಡೇಟಾ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸುವಾಗ ನಾವು ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ, ಆದರೆ ನಾವು ಅವುಗಳನ್ನು ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಈಗ ಈ ಸಮಸ್ಯೆಗಳು ಹೋಗಿವೆ.

ಮರ್ಕಲ್ ಮರವನ್ನು ರೂಪಿಸುವುದು ಮತ್ತು ಹ್ಯಾಶ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು 1 000 000 ವಹಿವಾಟುಗಳು ಸುಮಾರು ಅಗತ್ಯವಿದೆ 10 ನಿರಂತರ ಲೆಕ್ಕಾಚಾರದ ಸೆಕೆಂಡುಗಳು. ಈ ಸಮಯದಲ್ಲಿ, ಎಲ್ಲಾ ನೋಡ್ಗಳೊಂದಿಗಿನ ಸಂಪರ್ಕವು ಮುರಿಯಲು ನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ಲೆಕ್ಕಾಚಾರವನ್ನು ಪ್ರತ್ಯೇಕ ಥ್ರೆಡ್ಗೆ ಸರಿಸಲು ನಿರ್ಧರಿಸಲಾಯಿತು.

ತೀರ್ಮಾನಗಳು:

ವಾಸ್ತವವಾಗಿ, ನಮ್ಮ ಸಂಶೋಧನೆಗಳು ಹೊಸದಲ್ಲ, ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಂದಾಗಿ ಅನೇಕ ತಜ್ಞರು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಅವುಗಳನ್ನು ಮರೆತುಬಿಡುತ್ತಾರೆ.

• ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಬದಲಿಗೆ ಕ್ರಿಯಾತ್ಮಕ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಅನ್ನು ಬಳಸುವುದು ಉತ್ಪಾದಕತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.
• ಏಕಶಿಲೆಯು ಉತ್ಪಾದಕ NodeJS ಸಿಸ್ಟಮ್‌ಗಾಗಿ ಸೇವಾ ವಾಸ್ತುಶಿಲ್ಪಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿದೆ.
• ಭಾರೀ ಕಂಪ್ಯೂಟೇಶನ್‌ಗಾಗಿ `ವರ್ಕರ್_ಥ್ರೆಡ್‌ಗಳನ್ನು' ಬಳಸುವುದು ಸಿಸ್ಟಂ ರೆಸ್ಪಾನ್ಸಿವ್‌ನೆಸ್ ಅನ್ನು ಸುಧಾರಿಸುತ್ತದೆ, ವಿಶೇಷವಾಗಿ i/o ಕಾರ್ಯಾಚರಣೆಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುವಾಗ.
• unix ಸಾಕೆಟ್ http ವಿನಂತಿಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸ್ಥಿರವಾಗಿದೆ ಮತ್ತು ವೇಗವಾಗಿರುತ್ತದೆ.
• ನೀವು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ದೊಡ್ಡ ಡೇಟಾವನ್ನು ತ್ವರಿತವಾಗಿ ವರ್ಗಾಯಿಸಬೇಕಾದರೆ, ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳನ್ನು ಬಳಸುವುದು ಮತ್ತು ಬೈನರಿ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವುದು ಉತ್ತಮ, ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ, ಅವುಗಳು ಬರದಿದ್ದರೆ ಅದನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಬಹುದು ಮತ್ತು ನಂತರ ಒಂದು ಸಂದೇಶಕ್ಕೆ ಸಂಯೋಜಿಸಬಹುದು.

ನಾವು ನಿಮ್ಮನ್ನು ಭೇಟಿ ಮಾಡಲು ಆಹ್ವಾನಿಸುತ್ತೇವೆ GitHub ಯೋಜನೆ: https://github.com/opporty-com/Plasma-Cash/tree/new-version

ಲೇಖನವನ್ನು ಸಹ-ಬರೆದಿದ್ದಾರೆ ಅಲೆಕ್ಸಾಂಡರ್ ನಾಶಿವಾನ್, ಹಿರಿಯ ಡೆವಲಪರ್ ಬುದ್ಧಿವಂತ ಪರಿಹಾರ ಇಂಕ್.

ಮೂಲ: www.habr.com