ಎಥೆರಿಯಮ್ ಶ್ವೇತಪತ್ರ
ಈ ಪರಿಚಯಾತ್ಮಕ ಪತ್ರವನ್ನು ಮೂಲತಃ 2014 ರಲ್ಲಿ ಎಥೆರಿಯಮ್ನ ಸಂಸ್ಥಾಪಕ ವಿಟಾಲಿಕ್ ಬ್ಯೂಟರಿನ್ ಅವರು 2015 ರಲ್ಲಿ ಯೋಜನೆಯ ಪ್ರಾರಂಭಕ್ಕೆ ಮುನ್ನ ಪ್ರಕಟಿಸಿದರು. ಹಲವಾರು ಸಮುದಾಯ-ಚಾಲಿತ, ಓಪನ್-ಸೋರ್ಸ್ ಸಾಫ್ಟ್ವೇರ್ ಯೋಜನೆಗಳಂತೆ ಎಥೆರಿಯಮ್ ಕೂಡ ತನ್ನ ಆರಂಭಿಕ ರೂಪುರೇಷೆಯಿಂದ ವಿಕಾಸಗೊಂಡಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯ.
ಹಲವು ವರ್ಷಗಳ ಹಿಂದಿನದಾದರೂ, ಈ ಪತ್ರವು ಎಥೆರಿಯಮ್ ಮತ್ತು ಅದರ ದೃಷ್ಟಿಕೋನದ ಉಪಯುಕ್ತ ಉಲ್ಲೇಖ ಮತ್ತು ನಿಖರವಾದ ಪ್ರತಿನಿಧಿಯಾಗಿ ಮುಂದುವರಿಯುತ್ತಿರುವುದರಿಂದ ನಾವು ಇದನ್ನು ಕಾಪಾಡಿಕೊಂಡಿದ್ದೇವೆ. ಎಥೆರಿಯಮ್ನ ಇತ್ತೀಚಿನ ಬೆಳವಣಿಗೆಗಳು ಮತ್ತು ಶಿಷ್ಟಾಚಾರದಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಹೇಗೆ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ತಿಳಿಯಲು, ನಾವು ಈ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.
ಮುಂದಿನ-ಪೀಳಿಗೆಯ ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದ ಮತ್ತು ವಿಕೇಂದ್ರೀಕೃತ ಅಪ್ಲಿಕೇಶನ್ ವೇದಿಕೆ
2009 ರಲ್ಲಿ ಸತೋಷಿ ನಕಮೋಟೊ ಅವರ ಬಿಟ್ಕಾಯಿನ್ ಅಭಿವೃದ್ಧಿಯನ್ನು ಹಣ ಮತ್ತು ಕರೆನ್ಸಿಯಲ್ಲಿ ಮೂಲಭೂತ ಬೆಳವಣಿಗೆಯಾಗಿ ಹೊಗಳಲಾಗುತ್ತದೆ, ಇದು ಯಾವುದೇ ಬೆಂಬಲ ಅಥವಾ "ಅಂತರ್ಗತ ಮೌಲ್ಯ"(opens in a new tab) ಮತ್ತು ಯಾವುದೇ ಕೇಂದ್ರೀಕೃತ ನೀಡುಗ ಅಥವಾ ನಿಯಂತ್ರಕ ಇಲ್ಲದ ಮೊದಲ ಡಿಜಿಟಲ್ ಆಸ್ತಿಯ ಉದಾಹರಣೆಯಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಬಿಟ್ಕಾಯಿನ್ ಪ್ರಯೋಗದ ಮತ್ತೊಂದು, ಬಹುಶಃ ಹೆಚ್ಚು ಮುಖ್ಯವಾದ ಭಾಗವೆಂದರೆ ವಿತರಿತ ಒಮ್ಮತದ ಸಾಧನವಾಗಿ ಅಂತರ್ನಿಹಿತ ಬ್ಲಾಕ್ಚೈನ್ ತಂತ್ರಜ್ಞಾನ, ಮತ್ತು ಬಿಟ್ಕಾಯಿನ್ನ ಈ ಇತರ ಅಂಶಕ್ಕೆ ಗಮನವು ವೇಗವಾಗಿ ಬದಲಾಗುತ್ತಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಉಲ್ಲೇಖಿಸಲಾದ ಬ್ಲಾಕ್ಚೈನ್ ತಂತ್ರಜ್ಞಾನದ ಪರ್ಯಾಯ ಅಪ್ಲಿಕೇಶನ್ಗಳಲ್ಲಿ ಕಸ್ಟಮ್ ಕರೆನ್ಸಿಗಳು ಮತ್ತು ಹಣಕಾಸು ಸಾಧನಗಳನ್ನು(opens in a new tab) ("ಬಣ್ಣದ ನಾಣ್ಯಗಳು") ಪ್ರತಿನಿಧಿಸಲು ಆನ್-ಬ್ಲಾಕ್ಚೈನ್ ಡಿಜಿಟಲ್ ಆಸ್ತಿಗಳನ್ನು ಬಳಸುವುದು, ಅಂತರ್ನಿಹಿತ ಭೌತಿಕ ಸಾಧನದ ಮಾಲೀಕತ್ವ ("ಸ್ಮಾರ್ಟ್ ಆಸ್ತಿ(opens in a new tab)"), ಡೊಮೇನ್ ಹೆಸರುಗಳಂತಹ ಅವಿಭಾಜ್ಯ ಆಸ್ತಿಗಳು(opens in a new tab)("ನೇಮ್ಕಾಯಿನ್"), ಹಾಗೆಯೇ ಯಾದೃಚ್ಛಿಕ ನಿಯಮಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಕೋಡ್ನ ತುಣುಕಿನಿಂದ ನೇರವಾಗಿ ನಿಯಂತ್ರಿಸಲ್ಪಡುವ ಡಿಜಿಟಲ್ ಆಸ್ತಿಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಅಪ್ಲಿಕೇಶನ್ಗಳು ("ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದಗಳು(opens in a new tab)") ಅಥವಾ ಬ್ಲಾಕ್ಚೈನ್ ಆಧಾರಿತ "ವಿಕೇಂದ್ರೀಕೃತ ಸ್ವಾಯತ್ತ ಸಂಸ್ಥೆಗಳು"(opens in a new tab) (DAOs) ಸೇರಿವೆ. ಎಥೆರಿಯಮ್ ಒದಗಿಸಲು ಉದ್ದೇಶಿಸಿರುವುದು ಅಂತರ್ನಿರ್ಮಿತ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯೊಂದಿಗಿನ ಬ್ಲಾಕ್ಚೈನ್ ಆಗಿದೆ, ಅದನ್ನು ಯಾದೃಚ್ಛಿಕ ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯಗಳನ್ನು ಎನ್ಕೋಡ್ ಮಾಡಲು ಬಳಸಬಹುದಾದ "ಒಪ್ಪಂದಗಳನ್ನು" ರಚಿಸಲು ಬಳಸಬಹುದು, ಇದರಿಂದ ಬಳಕೆದಾರರು ಮೇಲೆ ವಿವರಿಸಿದ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಗಳನ್ನು ರಚಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಹಾಗೆಯೇ ನಾವು ಇನ್ನೂ ಊಹಿಸಿಲ್ಲದ ಇತರ ಹಲವಾರು ವ್ಯವಸ್ಥೆಗಳನ್ನು, ಕೇವಲ ಕೆಲವು ಸಾಲುಗಳ ಕೋಡ್ನಲ್ಲಿ ತರ್ಕವನ್ನು ಬರೆಯುವ ಮೂಲಕ ರಚಿಸಬಹುದು.
ಬಿಟ್ಕಾಯಿನ್ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಕಲ್ಪನೆಗಳ ಪರಿಚಯ
ಇತಿಹಾಸ
ವಿಕೇಂದ್ರೀಕೃತ ಡಿಜಿಟಲ್ ಕರೆನ್ಸಿಯ ಪರಿಕಲ್ಪನೆ, ಹಾಗೆಯೇ ಆಸ್ತಿ ನೋಂದಣಿಗಳಂತಹ ಪರ್ಯಾಯ ಅಪ್ಲಿಕೇಶನ್ಗಳು ದಶಕಗಳಿಂದ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. 1980 ಮತ್ತು 1990 ರ ದಶಕಗಳ ಅನಾಮಧೇಯ ಇ-ಕ್ಯಾಷ್ ಶಿಷ್ಟಾಚಾರಗಳು, ಹೆಚ್ಚಾಗಿ ಚೌಮಿಯನ್ ಬ್ಲೈಂಡಿಂಗ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಗೂಢಲಿಪಿ ಪ್ರಾಥಮಿಕವನ್ನು ಅವಲಂಬಿಸಿದ್ದವು, ಅವು ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಗೌಪ್ಯತೆಯೊಂದಿಗೆ ಕರೆನ್ಸಿಯನ್ನು ಒದಗಿಸಿದವು, ಆದರೆ ಪ್ರೊಟೋಕಾಲ್ಗಳು ಕೇಂದ್ರೀಕೃತ ಮಧ್ಯವರ್ತಿಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದ ಕಾರಣ ಹೆಚ್ಚಾಗಿ ಆಕರ್ಷಣೆ ಪಡೆಯಲು ವಿಫಲವಾದವು. 1998 ರಲ್ಲಿ, ವೇಯ್ ಡೈ ಅವರ ಬೀ-ಮನಿ(opens in a new tab) ಕಂಪ್ಯೂಟೇಶನಲ್ ಒಗಟುಗಳನ್ನು ಪರಿಹರಿಸುವ ಮೂಲಕ ಹಣವನ್ನು ಸೃಷ್ಟಿಸುವ ಕಲ್ಪನೆಯನ್ನು, ಹಾಗೆಯೇ ವಿಕೇಂದ್ರೀಕೃತ ಒಮ್ಮತವನ್ನು ಪರಿಚಯಿಸಿದ ಮೊದಲ ಪ್ರಸ್ತಾಪವಾಗಿತ್ತು, ಆದರೆ ವಿಕೇಂದ್ರೀಕೃತ ಒಮ್ಮತವನ್ನು ವಾಸ್ತವವಾಗಿ ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ಪ್ರಸ್ತಾಪದಲ್ಲಿ ಹೆಚ್ಚು ವಿವರಗಳು ಇರಲಿಲ್ಲ. 2005 ರಲ್ಲಿ, ಹಾಲ್ ಫಿನ್ನಿ "ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಕೆಲಸದ ಪುರಾವೆಗಳು"(opens in a new tab) ಎಂಬ ಪರಿಕಲ್ಪನೆಯನ್ನು ಪರಿಚಯಿಸಿದರು, ಇದು ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿ ಪರಿಕಲ್ಪನೆಯನ್ನು ರಚಿಸಲು ಬಿ-ಮನಿಯಿಂದ ಪಡೆದ ಕಲ್ಪನೆಗಳನ್ನು ಆಡಮ್ ಬ್ಯಾಕ್ನ ಕಂಪ್ಯೂಟೇಶನಲ್ ಕಷ್ಟಕರವಾದ ಹ್ಯಾಶ್ಕ್ಯಾಶ್ ಒಗಟುಗಳೊಂದಿಗೆ ಬಳಸುವ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ, ಆದರೆ ಮತ್ತೆ ಬ್ಯಾಕ್ಎಂಡ್ ಆಗಿ ವಿಶ್ವಾಸಾರ್ಹ ಕಂಪ್ಯೂಟಿಂಗ್ ಅನ್ನು ಅವಲಂಬಿಸುವ ಮೂಲಕ ಆದರ್ಶವಾಗುವುದರಿಂದ ಹಿಂದೆ ಬಿತ್ತು. 2009 ರಲ್ಲಿ, ವಿಕೇಂದ್ರೀಕೃತ ಕರೆನ್ಸಿಯನ್ನು ಮೊದಲ ಬಾರಿಗೆ ಸತೋಷಿ ನಕಮೋಟೊ ಅವರು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದರು, ಸಾರ್ವಜನಿಕ ಕೀಲಿ ಗೂಢಲಿಪಿಯ ಮೂಲಕ ಮಾಲೀಕತ್ವವನ್ನು ನಿರ್ವಹಿಸಲು ಸ್ಥಾಪಿತ ಪ್ರಾಥಮಿಕಗಳನ್ನು "ಪ್ರೂಫ್-ಆಫ್-ವರ್ಕ್" ಎಂದು ಕರೆಯಲ್ಪಡುವ ನಾಣ್ಯಗಳನ್ನು ಯಾರು ಹೊಂದಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಒಮ್ಮತದ ಅಲ್ಗಾರಿದಮ್ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಿದರು.
ಪ್ರೂಫ್-ಆಫ್-ವರ್ಕ್ನ ಹಿಂದಿನ ಕಾರ್ಯವಿಧಾನವು ಈ ಕ್ಷೇತ್ರದಲ್ಲಿ ಮಹತ್ವದ ಮುನ್ನಡೆಯಾಗಿತ್ತು, ಏಕೆಂದರೆ ಅದು ಏಕಕಾಲದಲ್ಲಿ ಎರಡು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿತು. ಮೊದಲನೆಯದಾಗಿ, ಇದು ಸರಳ ಮತ್ತು ಸಾಧಾರಣ ಪರಿಣಾಮಕಾರಿ ಒಮ್ಮತದ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಒದಗಿಸಿತು, ಇದು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿನ ನೋಡ್ಗಳಿಗೆ ಬಿಟ್ಕಾಯಿನ್ ಲೆಡ್ಜರ್ನ ಸ್ಥಿತಿಗೆ ಕ್ಯಾನೊನಿಕಲ್ ನವೀಕರಣಗಳ ಗುಂಪಿನ ಮೇಲೆ ಸಾಮೂಹಿಕವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳಲು ಅನುವು ಮಾಡಿಕೊಟ್ಟಿತು. ಎರಡನೆಯದಾಗಿ, ಇದು ಒಮ್ಮತದ ಪ್ರಕ್ರಿಯೆಗೆ ಉಚಿತ ಪ್ರವೇಶಕ್ಕೆ ಅನುವು ಮಾಡಿಕೊಡುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ಒದಗಿಸಿತು, ಒಮ್ಮತದ ಮೇಲೆ ಯಾರು ಪ್ರಭಾವ ಬೀರಬೇಕು ಎಂಬ ರಾಜಕೀಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿತು, ಅದೇ ಸಮಯದಲ್ಲಿ ಸಿಬಿಲ್ ದಾಳಿಗಳನ್ನು ತಡೆಯಿತು. ಇದು ಭಾಗವಹಿಸುವಿಕೆಗೆ ಔಪಚಾರಿಕ ತಡೆಯನ್ನು, ಉದಾಹರಣೆಗೆ ನಿರ್ದಿಷ್ಟ ಪಟ್ಟಿಯಲ್ಲಿ ಅನನ್ಯ ಘಟಕವಾಗಿ ನೋಂದಾಯಿಸಲ್ಪಡುವ ಅಗತ್ಯತೆಯನ್ನು, ಆರ್ಥಿಕ ತಡೆಯೊಂದಿಗೆ ಬದಲಾಯಿಸುವ ಮೂಲಕ ಇದನ್ನು ಮಾಡುತ್ತದೆ - ಒಮ್ಮತದ ಮತದಾನ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಒಂದು ನೋಡ್ನ ತೂಕವು ಆ ನೋಡ್ ತರುವ ಕಂಪ್ಯೂಟಿಂಗ್ ಶಕ್ತಿಗೆ ನೇರ ಅನುಪಾತದಲ್ಲಿರುತ್ತದೆ. ಅಂದಿನಿಂದ, ಪ್ರೂಫ್-ಆಫ್-ಸ್ಟೇಕ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಪರ್ಯಾಯ ವಿಧಾನವನ್ನು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ, ಇದು ನೋಡ್ನ ತೂಕವನ್ನು ಅದರ ಕರೆನ್ಸಿ ಹೊಂದಿರುವಿಕೆಗೆ ಅನುಗುಣವಾಗಿ ಲೆಕ್ಕಹಾಕುತ್ತದೆ ಮತ್ತು ಕಂಪ್ಯೂಟೇಶನಲ್ ಸಂಪನ್ಮೂಲಗಳಿಗಲ್ಲ; ಎರಡು ವಿಧಾನಗಳ ಸಾಪೇಕ್ಷ ಗುಣಗಳ ಚರ್ಚೆಯು ಈ ಪತ್ರದ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿದೆ ಆದರೆ ಎರಡೂ ವಿಧಾನಗಳನ್ನು ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿಯ ಬೆನ್ನೆಲುಬಾಗಿ ಬಳಸಬಹುದು ಎಂಬುದನ್ನು ಗಮನಿಸಬೇಕು.
ಸ್ಥಿತಿಯ ಪರಿವರ್ತನೆ ವ್ಯವಸ್ಥೆಯಾಗಿ ಬಿಟ್ಕಾಯಿನ್
ತಾಂತ್ರಿಕ ದೃಷ್ಟಿಕೋನದಿಂದ, ಬಿಟ್ಕಾಯಿನ್ನಂತಹ ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿಯ ಲೆಡ್ಜರ್ ಅನ್ನು ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ವ್ಯವಸ್ಥೆಯೆಂದು ಪರಿಗಣಿಸಬಹುದು, ಅಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಎಲ್ಲಾ ಬಿಟ್ಕಾಯಿನ್ಗಳ ಮಾಲೀಕತ್ವದ ಸ್ಥಿತಿಯನ್ನು ಒಳಗೊಂಡಿರುವ "ಸ್ಥಿತಿ" ಮತ್ತು ಸ್ಥಿತಿ ಮತ್ತು ವಹಿವಾಟನ್ನು ತೆಗೆದುಕೊಂಡು ಹೊಸ ಸ್ಥಿತಿಯನ್ನು ಔಟ್ಪುಟ್ ಮಾಡುವ "ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯ" ಇರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಪ್ರಮಾಣಿತ ಬ್ಯಾಂಕಿಂಗ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಸ್ಥಿತಿಯು ಬ್ಯಾಲೆನ್ಸ್ ಶೀಟ್ ಆಗಿದೆ, ವಹಿವಾಟು ಎಂದರೆ A ಯಿಂದ B ಗೆ $X ಅನ್ನು ಸ್ಥಳಾಂತರಿಸುವ ವಿನಂತಿ, ಮತ್ತು ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯವು A ಯ ಖಾತೆಯಲ್ಲಿನ ಮೌಲ್ಯವನ್ನು $X ರಷ್ಟು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು B ಯ ಖಾತೆಯಲ್ಲಿನ ಮೌಲ್ಯವನ್ನು $X ರಷ್ಟು ಹೆಚ್ಚಿಸುತ್ತದೆ. A ಯ ಖಾತೆಯಲ್ಲಿ ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ $X ಗಿಂತ ಕಡಿಮೆ ಇದ್ದರೆ, ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯವು ದೋಷವನ್ನು ತೋರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಒಬ್ಬರು ಔಪಚಾರಿಕವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು:
APPLY(S,TX) -> S' or ERROR
ಮೇಲೆ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಬ್ಯಾಂಕಿಂಗ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ:
APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }
ಆದರೆ:
APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR
ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿ "ಸ್ಥಿತಿ" ಎಂಬುದು ಖನನ ಮಾಡಲಾಗಿದ್ದು ಇನ್ನೂ ಖರ್ಚು ಮಾಡದ ಎಲ್ಲಾ ನಾಣ್ಯಗಳ (ತಾಂತ್ರಿಕವಾಗಿ, "ಖರ್ಚು ಮಾಡದ ವ್ಯವಹಾರ ಔಟ್ಪುಟ್ಗಳು" ಅಥವಾ UTXO) ಸಂಗ್ರಹವಾಗಿದೆ. ಪ್ರತಿ UTXO ಒಂದು ಮೌಲ್ಯ ಮತ್ತು ಒಬ್ಬ ಮಾಲೀಕನನ್ನು ಹೊಂದಿರುತ್ತದೆ (20-ಬೈಟ್ ವಿಳಾಸದಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ, ಇದು ಮೂಲತಃ ಒಂದು ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯಾಗಿದೆfn1). ಒಂದು ವ್ಯವಹಾರವು ಒಂದು ಅಥವಾ ಹೆಚ್ಚು ಇನ್ಪುಟ್ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಪ್ರತಿ ಇನ್ಪುಟ್ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ UTXO ಗೆ ಉಲ್ಲೇಖವನ್ನು ಮತ್ತು ಮಾಲೀಕನ ವಿಳಾಸಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಖಾಸಗಿ ಕೀಲಿಯಿಂದ ಉತ್ಪಾದಿಸಲಾದ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಸಹಿಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಮತ್ತು ಒಂದು ಅಥವಾ ಹೆಚ್ಚು ಔಟ್ಪುಟ್ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಪ್ರತಿ ಔಟ್ಪುಟ್ ಸ್ಥಿತಿಗೆ ಸೇರಿಸಬೇಕಾದ ಹೊಸ UTXO ವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.
ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯವನ್ನುAPPLY(S,TX) -> S'
ಎಂದು ಈ ರೀತಿ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು:
TX
ನಲ್ಲಿನ ಪ್ರತಿ ಇನ್ಪುಟ್ಗಾಗಿ:- ಉಲ್ಲೇಖಿಸಿದ UTXO
S
ನಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ, ದೋಷವನ್ನು ತೋರಿಸುತ್ತದೆ. - ಒದಗಿಸಿದ ಸಹಿ UTXO ನ ಮಾಲೀಕರಿಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ದೋಷವನ್ನು ತೋರಿಸುತ್ತದೆ.
- ಉಲ್ಲೇಖಿಸಿದ UTXO
- ಎಲ್ಲಾ ಇನ್ಪುಟ್ UTXO ಗಳ ಮೌಲ್ಯಗಳ ಮೊತ್ತವು ಎಲ್ಲಾ ಔಟ್ಪುಟ್ UTXO ಗಳ ಮೌಲ್ಯಗಳ ಮೊತ್ತಕ್ಕಿಂತ ಕಡಿಮೆಯಾಗಿದ್ದರೆ, ದೋಷವನ್ನು ತೋರಿಸುತ್ತದೆ.
- ಎಲ್ಲಾ ಇನ್ಪುಟ್ UTXO ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ ಮತ್ತು ಎಲ್ಲಾ ಔಟ್ಪುಟ್ UTXO ಗಳನ್ನು ಸೇರಿಸಿದ
S
ಅನ್ನು ತೋರಿಸುತ್ತದೆ.
ಮೊದಲ ಹಂತದ ಮೊದಲ ಭಾಗವು ವ್ಯವಹಾರ ಕಳುಹಿಸುವವರು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ನಾಣ್ಯಗಳನ್ನು ಖರ್ಚು ಮಾಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಮೊದಲ ಹಂತದ ಎರಡನೇ ಭಾಗವು ವ್ಯವಹಾರ ಕಳುಹಿಸುವವರು ಇತರರ ನಾಣ್ಯಗಳನ್ನು ಖರ್ಚು ಮಾಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಮತ್ತು ಎರಡನೇ ಹಂತವು ಮೌಲ್ಯದ ಸಂರಕ್ಷಣೆಯನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ. ಇದನ್ನು ಪಾವತಿಗಾಗಿ ಬಳಸಲು, ಪ್ರೋಟೋಕಾಲ್ ಈ ರೀತಿ ಇರುತ್ತದೆ. ಆಲಿಸ್ ಬಾಬ್ಗೆ 11.7 BTC ಕಳುಹಿಸಲು ಬಯಸುತ್ತಾಳೆ ಎಂದು ಭಾವಿಸೋಣ. ಮೊದಲಿಗೆ, ಆಲಿಸ್ ತನ್ನ ಒಡೆತನದಲ್ಲಿರುವ ಕನಿಷ್ಠ 11.7 BTC ಗೆ ಸಮನಾಗುವ ಲಭ್ಯವಿರುವ UTXO ಗಳ ಸಮೂಹವನ್ನು ಹುಡುಕುತ್ತಾಳೆ. ವಾಸ್ತವವಾಗಿ, ಆಲಿಸ್ಗೆ ನಿಖರವಾಗಿ 11.7 BTC ಪಡೆಯಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ; ಅವಳು ಪಡೆಯಬಹುದಾದ ಕನಿಷ್ಠ ಮೊತ್ತ 6+4+2=12 ಎಂದು ಭಾವಿಸೋಣ. ನಂತರ ಅವಳು ಆ ಮೂರು ಇನ್ಪುಟ್ಗಳು ಮತ್ತು ಎರಡು ಔಟ್ಪುಟ್ಗಳೊಂದಿಗೆ ಒಂದು ವ್ಯವಹಾರವನ್ನು ರಚಿಸುತ್ತಾಳೆ. ಮೊದಲ ಔಟ್ಪುಟ್ 11.7 BTC ಆಗಿರುತ್ತದೆ, ಅದರ ಮಾಲೀಕರಾಗಿ ಬಾಬ್ನ ವಿಳಾಸವಿರುತ್ತದೆ, ಮತ್ತು ಎರಡನೇ ಔಟ್ಪುಟ್ ಉಳಿದ 0.3 BTC "ಬದಲಾವಣೆ" ಆಗಿರುತ್ತದೆ, ಆಲಿಸ್ ಸ್ವತಃ ಅದರ ಮಾಲೀಕರಾಗಿರುತ್ತಾರೆ.
ಗಣಿಗಾರಿಕೆ
ನಂಬಲರ್ಹವಾದ ಕೇಂದ್ರೀಕೃತ ಸೇವೆಗೆ ನಮಗೆ ಪ್ರವೇಶವಿದ್ದರೆ, ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು ಸುಲಭವಾಗಿರುತ್ತಿತ್ತು; ಇದನ್ನು ವಿವರಿಸಿದಂತೆಯೇ ನಿಖರವಾಗಿ ಕೋಡ್ ಮಾಡಬಹುದಾಗಿತ್ತು, ಸ್ಥಿತಿಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಕೇಂದ್ರೀಕೃತ ಸರ್ವರ್ನ ಹಾರ್ಡ್ಡ್ರೈವ್ ಅನ್ನು ಬಳಸಿ. ಆದರೆ, ಬಿಟ್ಕಾಯಿನ್ನೊಂದಿಗೆ ನಾವು ವಿಕೇಂದ್ರೀಕೃತ ಕರೆನ್ಸಿ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಎಲ್ಲರೂ ವ್ಯವಹಾರಗಳ ಕ್ರಮದ ಬಗ್ಗೆ ಒಪ್ಪಿಕೊಳ್ಳುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಒಮ್ಮತ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಬೇಕಾಗುತ್ತದೆ. ಬಿಟ್ಕಾಯಿನ್ನ ವಿಕೇಂದ್ರೀಕೃತ ಒಮ್ಮತ ಪ್ರಕ್ರಿಯೆಗೆ "ಬ್ಲಾಕ್ಗಳು" ಎಂದು ಕರೆಯಲ್ಪಡುವ ವ್ಯವಹಾರಗಳ ಪ್ಯಾಕೇಜ್ಗಳನ್ನು ನಿರಂತರವಾಗಿ ಉತ್ಪಾದಿಸಲು ಪ್ರಯತ್ನಿಸಲು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿನ ನೋಡ್ಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ ಪ್ರತಿ ಹತ್ತು ನಿಮಿಷಕ್ಕೊಮ್ಮೆ ಒಂದು ಬ್ಲಾಕ್ ಅನ್ನು ಉತ್ಪಾದಿಸುವ ಉದ್ದೇಶವನ್ನು ಹೊಂದಿದೆ, ಪ್ರತಿ ಬ್ಲಾಕ್ ಒಂದು ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್, ಒಂದು ನಾನ್ಸ್, ಹಿಂದಿನ ಬ್ಲಾಕ್ಗೆ ಉಲ್ಲೇಖ (ಅಂದರೆ ಹ್ಯಾಶ್) ಮತ್ತು ಹಿಂದಿನ ಬ್ಲಾಕ್ನಿಂದ ನಡೆದ ಎಲ್ಲಾ ವ್ಯವಹಾರಗಳ ಪಟ್ಟಿಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಕಾಲಾನಂತರದಲ್ಲಿ, ಇದು ನಿರಂತರವಾಗಿ ಬೆಳೆಯುತ್ತಿರುವ "ಬ್ಲಾಕ್ಚೈನ್" ಅನ್ನು ರಚಿಸುತ್ತದೆ, ಇದು ಬಿಟ್ಕಾಯಿನ್ ಲೆಡ್ಜರ್ನ ಇತ್ತೀಚಿನ ಸ್ಥಿತಿಯನ್ನು ಪ್ರತಿನಿಧಿಸಲು ನಿರಂತರವಾಗಿ ನವೀಕರಿಸುತ್ತದೆ.
ಒಂದು ಬ್ಲಾಕ್ ಮಾನ್ಯವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವ ಅಲ್ಗಾರಿದಮ್, ಈ ಮಾದರಿಯಲ್ಲಿ ವ್ಯಕ್ತಪಡಿಸಿದಂತೆ, ಈ ರೀತಿ ಇದೆ:
- ಬ್ಲಾಕ್ನಿಂದ ಉಲ್ಲೇಖಿಸಲಾದ ಹಿಂದಿನ ಬ್ಲಾಕ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಮಾನ್ಯವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
- ಬ್ಲಾಕ್ನ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಹಿಂದಿನ ಬ್ಲಾಕ್ನ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ಗಿಂತ ಹೆಚ್ಚಾಗಿದೆfn2 ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ 2 ಗಂಟೆಗಳಿಗಿಂತ ಕಡಿಮೆ ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ
- ಬ್ಲಾಕ್ನಲ್ಲಿನ ಪ್ರೂಫ್-ಆಫ್-ವರ್ಕ್ ಮಾನ್ಯವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
S[0]
ಹಿಂದಿನ ಬ್ಲಾಕ್ನ ಕೊನೆಯಲ್ಲಿನ ಸ್ಥಿತಿ ಎಂದು ಭಾವಿಸಿ.TX
ಬ್ಲಾಕ್ನn
ವ್ಯವಹಾರಗಳ ಪಟ್ಟಿ ಎಂದು ಭಾವಿಸಿ.0...n-1
ರಲ್ಲಿನ ಎಲ್ಲಾi
ಗಾಗಿ,S[i+1] = APPLY(S[i],TX[i])
ಎಂದು ಹೊಂದಿಸಿ. ಯಾವುದೇ ಅನ್ವಯ ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ, ನಿರ್ಗಮಿಸಿ ಮತ್ತು false ಹಿಂತಿರುಗಿಸಿ.- true ಹಿಂತಿರುಗಿಸಿ, ಮತ್ತು
S[n]
ಅನ್ನು ಈ ಬ್ಲಾಕ್ನ ಕೊನೆಯಲ್ಲಿನ ಸ್ಥಿತಿಯಾಗಿ ನೋಂದಾಯಿಸಿ.
ಮುಖ್ಯವಾಗಿ, ಬ್ಲಾಕ್ನಲ್ಲಿನ ಪ್ರತಿ ವ್ಯವಹಾರವು ವ್ಯವಹಾರ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು ಇದ್ದ ಅಧಿಕೃತ ಸ್ಥಿತಿಯಿಂದ ಹೊಸ ಸ್ಥಿತಿಗೆ ಮಾನ್ಯವಾದ ಸ್ಥಿತಿ ಪರಿವರ್ತನೆಯನ್ನು ಒದಗಿಸಬೇಕು. ಸ್ಥಿತಿಯನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಬ್ಲಾಕ್ನಲ್ಲಿ ಎನ್ಕೋಡ್ ಮಾಡಲಾಗಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ; ಇದು ಕೇವಲ ಮೌಲ್ಯಮಾಪಕ ನೋಡ್ ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕಾದ ಒಂದು ವಿಮೂರ್ತೀಕರಣವಾಗಿದೆ ಮತ್ತು ಯಾವುದೇ ಬ್ಲಾಕ್ಗಾಗಿ ಕೇವಲ (ಸುರಕ್ಷಿತವಾಗಿ) ಪ್ರಾರಂಭ ಸ್ಥಿತಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಪ್ರತಿ ಬ್ಲಾಕ್ನಲ್ಲಿನ ಪ್ರತಿ ವ್ಯವಹಾರವನ್ನು ಕ್ರಮವಾಗಿ ಅನ್ವಯಿಸುವ ಮೂಲಕ ಲೆಕ್ಕಹಾಕಬಹುದು. ಅದಕ್ಕೂ ಹೆಚ್ಚಾಗಿ, ಗಣಿಗಾರನು ವ್ಯವಹಾರಗಳನ್ನು ಬ್ಲಾಕ್ನಲ್ಲಿ ಸೇರಿಸುವ ಕ್ರಮವು ಮುಖ್ಯ; ಒಂದು ಬ್ಲಾಕ್ನಲ್ಲಿ A ಮತ್ತು B ಎಂಬ ಎರಡು ವ್ಯವಹಾರಗಳಿದ್ದು B ಯು A ರಚಿಸಿದ UTXO ವನ್ನು ಖರ್ಚು ಮಾಡುತ್ತಿದ್ದರೆ, A ಯು B ಗಿಂತ ಮೊದಲು ಬಂದರೆ ಬ್ಲಾಕ್ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ.
ಮೇಲಿನ ಪಟ್ಟಿಯಲ್ಲಿ ಕಂಡುಬರುವ ಒಂದು ಮಾನ್ಯತೆಯ ಷರತ್ತು ಇತರ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಕಾಣಸಿಗದಿರುವುದು "ಪ್ರೂಫ್-ಆಫ್-ವರ್ಕ್" ನ ಅಗತ್ಯತೆಯಾಗಿದೆ. ನಿಖರವಾದ ಷರತ್ತೆಂದರೆ ಪ್ರತಿಯೊಂದು ಬ್ಲಾಕ್ನ ಡಬಲ್-SHA256 ಹ್ಯಾಶ್, 256-ಬಿಟ್ ಸಂಖ್ಯೆಯಾಗಿ ಪರಿಗಣಿಸಿದಾಗ, ಗತಿಶೀಲವಾಗಿ ಹೊಂದಾಣಿಕೆ ಮಾಡಲಾದ ಗುರಿಗಿಂತ ಕಡಿಮೆ ಇರಬೇಕು, ಇದು ಈ ಬರಹದ ಸಮಯದಲ್ಲಿ ಸುಮಾರು 2187 ಆಗಿದೆ. ಇದರ ಉದ್ದೇಶವೆಂದರೆ ಬ್ಲಾಕ್ ರಚನೆಯನ್ನು ಕಂಪ್ಯೂಟೇಷನಲ್ ಆಗಿ "ಕಠಿಣ" ಮಾಡುವುದು, ಇದರಿಂದ ಸಿಬಿಲ್ ಆಕ್ರಮಣಕಾರರು ಸಂಪೂರ್ಣ ಬ್ಲಾಕ್ಚೈನ್ ಅನ್ನು ತಮ್ಮ ಪರವಾಗಿ ಮರುರಚಿಸುವುದನ್ನು ತಡೆಯುವುದು. SHA256 ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅಪ್ರತ್ಯಾಶಿತ ಸ್ಯೂಡೊ-ರಾಂಡಮ್ ಫಂಕ್ಷನ್ ಆಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿರುವುದರಿಂದ, ಮಾನ್ಯ ಬ್ಲಾಕ್ ರಚಿಸಲು ಒಂದೇ ಮಾರ್ಗವೆಂದರೆ ಕೇವಲ ಪ್ರಯತ್ನ ಮತ್ತು ದೋಷ, ನಾನ್ಸ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ಹೆಚ್ಚಿಸುತ್ತಾ ಹೊಸ ಹ್ಯಾಶ್ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ ಎಂದು ನೋಡುವುದು.
ಪ್ರಸ್ತುತ ~2187 ಗುರಿಯಲ್ಲಿ, ಮಾನ್ಯ ಬ್ಲಾಕ್ ಕಂಡುಹಿಡಿಯಲು ನೆಟ್ವರ್ಕ್ ಸರಾಸರಿ ~269 ಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ; ಸಾಮಾನ್ಯವಾಗಿ, ನೆಟ್ವರ್ಕ್ನಲ್ಲಿನ ಯಾವುದಾದರೂ ನೋಡ್ ಪ್ರತಿ ಹತ್ತು ನಿಮಿಷಕ್ಕೊಮ್ಮೆ ಹೊಸ ಬ್ಲಾಕ್ ಉತ್ಪಾದಿಸುವಂತೆ ಪ್ರತಿ 2016 ಬ್ಲಾಕ್ಗಳಿಗೊಮ್ಮೆ ನೆಟ್ವರ್ಕ್ ಗುರಿಯನ್ನು ಮರುಹೊಂದಿಸುತ್ತದೆ. ಈ ಕಂಪ್ಯೂಟೇಷನಲ್ ಕೆಲಸಕ್ಕಾಗಿ ಗಣಿಗಾರರಿಗೆ ಪರಿಹಾರ ನೀಡಲು, ಪ್ರತಿ ಬ್ಲಾಕ್ನ ಗಣಿಗಾರನಿಗೆ ಎಲ್ಲಿಂದಲೂ 25 BTC ಯನ್ನು ತಮಗೆ ತಾವೇ ನೀಡುವ ವ್ಯವಹಾರವನ್ನು ಸೇರಿಸಲು ಅವಕಾಶ ನೀಡಲಾಗಿದೆ. ಇದಕ್ಕೆ ಹೆಚ್ಚುವರಿಯಾಗಿ, ಯಾವುದೇ ವ್ಯವಹಾರದಲ್ಲಿ ಅದರ ಔಟ್ಪುಟ್ಗಳಿಗಿಂತ ಇನ್ಪುಟ್ಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಒಟ್ಟು ಮೌಲ್ಯವಿದ್ದರೆ, ವ್ಯತ್ಯಾಸವನ್ನು "ವ್ಯವಹಾರ ಶುಲ್ಕ" ವಾಗಿ ಗಣಿಗಾರನಿಗೆ ನೀಡಲಾಗುತ್ತದೆ. ಆಕಸ್ಮಿಕವಾಗಿ, ಇದು BTC ವಿತರಿಸಲಾಗುವ ಏಕೈಕ ವಿಧಾನವಾಗಿದೆ; ಆರಂಭಿಕ ಸ್ಥಿತಿಯಲ್ಲಿ ಯಾವುದೇ ನಾಣ್ಯಗಳಿರಲಿಲ್ಲ.
ಗಣಿಗಾರಿಕೆಯ ಉದ್ದೇಶವನ್ನು ಉತ್ತಮವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ದುರುದ್ದೇಶಪೂರಿತ ಆಕ್ರಮಣಕಾರನ ಸಂದರ್ಭದಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸೋಣ. ಬಿಟ್ಕಾಯಿನ್ನ ಅಂತರ್ನಿಹಿತ ಕ್ರಿಪ್ಟೋಗ್ರಫಿ ಸುರಕ್ಷಿತವೆಂದು ತಿಳಿದಿರುವುದರಿಂದ, ಆಕ್ರಮಣಕಾರನು ಬಿಟ್ಕಾಯಿನ್ ವ್ಯವಸ್ಥೆಯ ನೇರವಾಗಿ ಕ್ರಿಪ್ಟೋಗ್ರಫಿಯಿಂದ ರಕ್ಷಿಸಲ್ಪಡದ ಒಂದು ಭಾಗವನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಳ್ಳುತ್ತಾನೆ: ವ್ಯವಹಾರಗಳ ಕ್ರಮ. ಆಕ್ರಮಣಕಾರನ ತಂತ್ರವು ಸರಳವಾಗಿದೆ:
- ಯಾವುದಾದರೂ ಉತ್ಪನ್ನಕ್ಕೆ ಬದಲಾಗಿ (ಆದ್ಯತೆಯ ಮೇರೆಗೆ ತ್ವರಿತ-ವಿತರಣೆಯ ಡಿಜಿಟಲ್ ಸರಕು) 100 BTC ಅನ್ನು ವ್ಯಾಪಾರಿಗೆ ಕಳುಹಿಸುವುದು
- ಉತ್ಪನ್ನದ ವಿತರಣೆಗಾಗಿ ಕಾಯುವುದು
- ಅದೇ 100 BTC ಅನ್ನು ತನಗೇ ಕಳುಹಿಸುವ ಮತ್ತೊಂದು ವ್ಯವಹಾರವನ್ನು ಮಾಡುವುದು
- ತನ್ನ ವ್ಯವಹಾರವೇ ಮೊದಲು ನಡೆಯಿತು ಎಂದು ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಒಪ್ಪಿಸಲು ಪ್ರಯತ್ನಿಸುವುದು.
ಹಂತ (1) ನಡೆದ ಕೆಲವು ನಿಮಿಷಗಳ ನಂತರ, ಯಾವುದಾದರೂ ಗಣಿಗಾರನು ಆ ವ್ಯವಹಾರವನ್ನು ಒಂದು ಬ್ಲಾಕ್ನಲ್ಲಿ ಸೇರಿಸುತ್ತಾನೆ, ಉದಾಹರಣೆಗೆ ಬ್ಲಾಕ್ ಸಂಖ್ಯೆ 270000. ಸುಮಾರು ಒಂದು ಗಂಟೆಯ ನಂತರ, ಆ ಬ್ಲಾಕ್ನ ನಂತರ ಸರಪಳಿಗೆ ಇನ್ನೂ ಐದು ಬ್ಲಾಕ್ಗಳು ಸೇರ್ಪಡೆಗೊಂಡಿರುತ್ತವೆ, ಪ್ರತಿಯೊಂದು ಬ್ಲಾಕ್ ಪರೋಕ್ಷವಾಗಿ ಆ ವ್ಯವಹಾರವನ್ನು ಸೂಚಿಸುತ್ತದೆ ಮತ್ತು ಹೀಗೆ ಅದನ್ನು "ದೃಢೀಕರಿಸುತ್ತದೆ". ಈ ಹಂತದಲ್ಲಿ, ವ್ಯಾಪಾರಿಯು ಪಾವತಿಯನ್ನು ಅಂತಿಮಗೊಂಡಿದೆ ಎಂದು ಒಪ್ಪಿಕೊಂಡು ಉತ್ಪನ್ನವನ್ನು ವಿತರಿಸುತ್ತಾನೆ; ಇದು ಡಿಜಿಟಲ್ ಸರಕು ಎಂದು ನಾವು ಭಾವಿಸುತ್ತಿರುವುದರಿಂದ, ವಿತರಣೆ ತಕ್ಷಣವೇ ಆಗುತ್ತದೆ. ಈಗ, ಆಕ್ರಮಣಕಾರನು 100 BTC ಅನ್ನು ತನಗೇ ಕಳುಹಿಸುವ ಮತ್ತೊಂದು ವ್ಯವಹಾರವನ್ನು ರಚಿಸುತ್ತಾನೆ. ಆಕ್ರಮಣಕಾರನು ಅದನ್ನು ಕೇವಲ ಬಿಡುಗಡೆ ಮಾಡಿದರೆ, ಆ ವ್ಯವಹಾರವನ್ನು ಸಂಸ್ಕರಿಸಲಾಗುವುದಿಲ್ಲ; ಗಣಿಗಾರರು APPLY(S,TX)
ಅನ್ನು ಚಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸಿ TX
ಇನ್ನು ಮುಂದೆ ಸ್ಥಿತಿಯಲ್ಲಿಲ್ಲದ UTXO ಅನ್ನು ಬಳಸುತ್ತಿದೆ ಎಂದು ಗಮನಿಸುತ್ತಾರೆ. ಆದ್ದರಿಂದ ಬದಲಾಗಿ, ಆಕ್ರಮಣಕಾರನು ಬ್ಲಾಕ್ಚೈನ್ನ "ಶಾಖೆ" ಯನ್ನು ರಚಿಸುತ್ತಾನೆ, ಅದೇ ಬ್ಲಾಕ್ 269999 ಅನ್ನು ಮೂಲವಾಗಿ ಸೂಚಿಸುವ ಬ್ಲಾಕ್ 270000 ನ ಮತ್ತೊಂದು ಆವೃತ್ತಿಯನ್ನು ಗಣಿಗಾರಿಕೆ ಮಾಡುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ, ಆದರೆ ಹಳೆಯ ವ್ಯವಹಾರದ ಬದಲು ಹೊಸ ವ್ಯವಹಾರವನ್ನು ಇರಿಸುತ್ತಾನೆ. ಬ್ಲಾಕ್ ಡೇಟಾ ಭಿನ್ನವಾಗಿರುವುದರಿಂದ, ಇದು ಪ್ರೂಫ್-ಆಫ್-ವರ್ಕ್ ಅನ್ನು ಮರುಮಾಡಬೇಕಾಗುತ್ತದೆ. ಇದಲ್ಲದೆ, ಆಕ್ರಮಣಕಾರನ ಬ್ಲಾಕ್ 270000 ನ ಹೊಸ ಆವೃತ್ತಿಯು ಭಿನ್ನ ಹ್ಯಾಶ್ ಹೊಂದಿರುವುದರಿಂದ, ಮೂಲ ಬ್ಲಾಕ್ಗಳಾದ 270001 ರಿಂದ 270005 ಅದನ್ನು "ಸೂಚಿಸುವುದಿಲ್ಲ"; ಹೀಗಾಗಿ, ಮೂಲ ಸರಪಳಿ ಮತ್ತು ಆಕ್ರಮಣಕಾರನ ಹೊಸ ಸರಪಳಿ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿವೆ. ನಿಯಮವೆಂದರೆ ಶಾಖೆಯಲ್ಲಿ ಅತಿ ಉದ್ದದ ಬ್ಲಾಕ್ಚೈನ್ ಅನ್ನು ಸತ್ಯವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನ್ಯಾಯಸಮ್ಮತ ಗಣಿಗಾರರು 270005 ಸರಪಳಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗ ಆಕ್ರಮಣಕಾರನು ಒಬ್ಬನೇ 270000 ಸರಪಳಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿರುತ್ತಾನೆ. ಆಕ್ರಮಣಕಾರನು ತನ್ನ ಬ್ಲಾಕ್ಚೈನ್ ಅನ್ನು ಅತಿ ಉದ್ದದ್ದಾಗಿ ಮಾಡಲು, ಅವನು ಉಳಿದ ನೆಟ್ವರ್ಕ್ಗಿಂತ ಹೆಚ್ಚಿನ ಕಂಪ್ಯೂಟೇಷನಲ್ ಶಕ್ತಿಯನ್ನು ಹೊಂದಿರಬೇಕಾಗುತ್ತದೆ (ಹೀಗಾಗಿ, "51% ದಾಳಿ").
ಮೆರ್ಕಲ್ ಮರಗಳು
ಎಡ: ಶಾಖೆಯ ಮಾನ್ಯತೆಯ ಪುರಾವೆ ನೀಡಲು ಮೆರ್ಕಲ್ ಮರದಲ್ಲಿ ಕೇವಲ ಸ್ವಲ್ಪ ಸಂಖ್ಯೆಯ ನೋಡ್ಗಳನ್ನು ಮಂಡಿಸಿದರೆ ಸಾಕಾಗುತ್ತದೆ.
ಬಲ: ಮೆರ್ಕಲ್ ಮರದ ಯಾವುದೇ ಭಾಗವನ್ನು ಬದಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ ಅಂತಿಮವಾಗಿ ಸರಪಳಿಯಲ್ಲಿ ಎಲ್ಲಾದರೂ ಅಸಂಗತತೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಬಿಟ್ಕಾಯಿನ್ನ ಒಂದು ಮುಖ್ಯ ಸ್ಕೇಲೇಬಿಲಿಟಿಯ ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ ಬ್ಲಾಕ್ ಅನ್ನು ಬಹು-ಮಟ್ಟದ ದತ್ತಾಂಶ ರಚನೆಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಒಂದು ಬ್ಲಾಕ್ನ "ಹ್ಯಾಶ್" ವಾಸ್ತವವಾಗಿ ಕೇವಲ ಬ್ಲಾಕ್ ಶಿರೋಲೇಖದ ಹ್ಯಾಶ್ ಆಗಿದೆ, ಇದು ಸುಮಾರು 200-ಬೈಟ್ ದತ್ತಾಂಶವಾಗಿದ್ದು ಇದರಲ್ಲಿ ಕಾಲಮುದ್ರೆ, ನಾನ್ಸ್, ಹಿಂದಿನ ಬ್ಲಾಕ್ ಹ್ಯಾಶ್ ಮತ್ತು ಮೆರ್ಕಲ್ ಮರ ಎಂಬ ದತ್ತಾಂಶ ರಚನೆಯ ಮೂಲ ಹ್ಯಾಶ್ ಒಳಗೊಂಡಿದೆ, ಇದು ಬ್ಲಾಕ್ನಲ್ಲಿನ ಎಲ್ಲ ವ್ಯವಹಾರಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಮೆರ್ಕಲ್ ಮರವು ಒಂದು ರೀತಿಯ ದ್ವಿಮಾನ ಮರವಾಗಿದ್ದು, ಇದು ನೋಡ್ಗಳ ಸಮೂಹದಿಂದ ರಚಿತವಾಗಿದೆ, ಮರದ ಕೆಳಗಿನ ಭಾಗದಲ್ಲಿ ಅಂತರ್ನಿಹಿತ ದತ್ತಾಂಶವನ್ನು ಹೊಂದಿರುವ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಎಲೆ ನೋಡ್ಗಳು, ಮಧ್ಯಂತರ ನೋಡ್ಗಳ ಸಮೂಹ ಇದರಲ್ಲಿ ಪ್ರತಿ ನೋಡ್ ಅದರ ಎರಡು ಮಕ್ಕಳ ಹ್ಯಾಶ್ ಆಗಿರುತ್ತದೆ, ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಒಂದು ಮೂಲ ನೋಡ್, ಇದು ಸಹ ಅದರ ಎರಡು ಮಕ್ಕಳ ಹ್ಯಾಶ್ನಿಂದ ರೂಪುಗೊಂಡಿದ್ದು, ಮರದ "ಮೇಲ್ಭಾಗ" ವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಮೆರ್ಕಲ್ ಮರದ ಉದ್ದೇಶವೆಂದರೆ ಬ್ಲಾಕ್ನಲ್ಲಿನ ದತ್ತಾಂಶವನ್ನು ತುಂಡುಗಳಾಗಿ ವಿತರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುವುದು: ಒಂದು ನೋಡ್ ಒಂದು ಮೂಲದಿಂದ ಬ್ಲಾಕ್ನ ಶಿರೋಲೇಖವನ್ನು ಮಾತ್ರ ಡೌನ್ಲೋಡ್ ಮಾಡಬಹುದು, ಮತ್ತೊಂದು ಮೂಲದಿಂದ ಅವರಿಗೆ ಸಂಬಂಧಿಸಿದ ಮರದ ಸಣ್ಣ ಭಾಗವನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡಬಹುದು, ಮತ್ತು ಇನ್ನೂ ಎಲ್ಲಾ ದತ್ತಾಂಶವು ಸರಿಯಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು. ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕಾರಣವೆಂದರೆ ಹ್ಯಾಶ್ಗಳು ಮೇಲ್ಮುಖವಾಗಿ ಹರಡುತ್ತವೆ: ದುರುದ್ದೇಶಪೂರಿತ ಬಳಕೆದಾರನು ಮೆರ್ಕಲ್ ಮರದ ಕೆಳಭಾಗದಲ್ಲಿ ನಕಲಿ ವ್ಯವಹಾರವನ್ನು ಬದಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಈ ಬದಲಾವಣೆಯು ಮೇಲಿನ ನೋಡ್ನಲ್ಲಿ ಬದಲಾವಣೆಯನ್ನುಂಟುಮಾಡುತ್ತದೆ, ನಂತರ ಅದರ ಮೇಲಿನ ನೋಡ್ನಲ್ಲಿ ಬದಲಾವಣೆಯನ್ನುಂಟುಮಾಡುತ್ತದೆ, ಕೊನೆಗೆ ಮರದ ಮೂಲವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಬ್ಲಾಕ್ನ ಹ್ಯಾಷ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಪ್ರೋಟೋಕಾಲ್ ಅದನ್ನು ಸಂಪೂರ್ಣ ಭಿನ್ನ ಬ್ಲಾಕ್ ಎಂದು ನೋಂದಾಯಿಸುತ್ತದೆ (ಬಹುಶಃ ಅಮಾನ್ಯ ಪ್ರೂಫ್-ಆಫ್-ವರ್ಕ್ ಹೊಂದಿರುತ್ತದೆ).
ಮೆರ್ಕಲ್ ಮರ ಪ್ರೋಟೋಕಾಲ್ ದೀರ್ಘಾವಧಿಯ ಸುಸ್ಥಿರತೆಗೆ ನಿಸ್ಸಂದೇಹವಾಗಿ ಅತ್ಯಗತ್ಯವಾಗಿದೆ. ಬಿಟ್ಕಾಯಿನ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿನ "ಪೂರ್ಣ ನೋಡ್", ಪ್ರತಿಯೊಂದು ಬ್ಲಾಕ್ನ ಸಂಪೂರ್ಣತೆಯನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ಸಂಸ್ಕರಿಸುವ ಒಂದು ನೋಡ್, 2014ರ ಏಪ್ರಿಲ್ ಹೊತ್ತಿಗೆ ಬಿಟ್ಕಾಯಿನ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಸುಮಾರು 15 GB ಡಿಸ್ಕ್ ಸ್ಥಳವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ತಿಂಗಳು ಒಂದು ಗಿಗಾಬೈಟ್ಗಿಂತ ಹೆಚ್ಚು ಬೆಳೆಯುತ್ತಿದೆ. ಪ್ರಸ್ತುತ, ಇದು ಕೆಲವು ಡೆಸ್ಕ್ಟಾಪ್ ಕಂಪ್ಯೂಟರ್ಗಳಿಗೆ ಸಾಧ್ಯವಾಗಿದೆ ಮತ್ತು ಫೋನ್ಗಳಿಗೆ ಅಲ್ಲ, ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ಕೇವಲ ವ್ಯಾಪಾರಗಳು ಮತ್ತು ಹವ್ಯಾಸಿಗಳು ಮಾತ್ರ ಭಾಗವಹಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. "ಸರಳೀಕೃತ ಪಾವತಿ ಪರಿಶೀಲನೆ" (SPV) ಎಂಬ ಪ್ರೋಟೋಕಾಲ್ ಇನ್ನೊಂದು ವರ್ಗದ ನೋಡ್ಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿರಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಇವುಗಳನ್ನು "ಲಘು ನೋಡ್ಗಳು" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಇವು ಬ್ಲಾಕ್ ಶಿರೋಲೇಖಗಳನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ, ಬ್ಲಾಕ್ ಶಿರೋಲೇಖಗಳ ಮೇಲೆ ಪ್ರೂಫ್-ಆಫ್-ವರ್ಕ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ, ಮತ್ತು ನಂತರ ಕೇವಲ ಅವುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ವ್ಯವಹಾರಗಳೊಂದಿಗೆ ಸಂಯೋಜಿತವಾದ "ಶಾಖೆಗಳನ್ನು" ಮಾತ್ರ ಡೌನ್ಲೋಡ್ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ. ಇದು ಲಘು ನೋಡ್ಗಳಿಗೆ ಸಂಪೂರ್ಣ ಬ್ಲಾಕ್ಚೈನ್ನ ಅತ್ಯಲ್ಪ ಭಾಗವನ್ನು ಮಾತ್ರ ಡೌನ್ಲೋಡ್ ಮಾಡಿಕೊಳ್ಳುವ ಮೂಲಕ ಯಾವುದೇ ಬಿಟ್ಕಾಯಿನ್ ವ್ಯವಹಾರದ ಸ್ಥಿತಿ ಮತ್ತು ಅವುಗಳ ಪ್ರಸ್ತುತ ಶಿಲ್ಕು ಏನು ಎಂಬುದನ್ನು ಬಲವಾದ ಭದ್ರತೆಯ ಖಾತರಿಯೊಂದಿಗೆ ನಿರ್ಧರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಪರ್ಯಾಯ ಬ್ಲಾಕ್ಚೈನ್ ಅನ್ವಯಗಳು
ಅಂತರ್ನಿಹಿತ ಬ್ಲಾಕ್ಚೈನ್ ಕಲ್ಪನೆಯನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಇತರ ಪರಿಕಲ್ಪನೆಗಳಿಗೆ ಅನ್ವಯಿಸುವ ಆಲೋಚನೆಯು ಸಹ ದೀರ್ಘ ಇತಿಹಾಸವನ್ನು ಹೊಂದಿದೆ. 2005 ರಲ್ಲಿ, ನಿಕ್ ಸಾಬೊ "ಮಾಲೀಕರ ಅಧಿಕಾರದೊಂದಿಗಿನ ಸುರಕ್ಷಿತ ಆಸ್ತಿ ಟೈಟಲ್ಗಳು"(opens in a new tab) ಎಂಬ ಪರಿಕಲ್ಪನೆಯನ್ನು ಮುಂದಿಟ್ಟರು. ಇದು "ಪ್ರತಿಕೃತಿ ಡೇಟಾಬೇಸ್ ತಂತ್ರಜ್ಞಾನದಲ್ಲಿನ ಹೊಸ ಪ್ರಗತಿಗಳು" ಯಾರು ಯಾವ ಭೂಮಿಯನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂಬುದರ ನೋಂದಣಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಬ್ಲಾಕ್ಚೈನ್ ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೇಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುವ ದಾಖಲೆಯಾಗಿತ್ತು.ಇದು ಹೋಮ್ಸ್ಟೇಡಿಂಗ್, ಪ್ರತಿಕೂಲ ಸ್ವಾಧೀನ ಮತ್ತು ಜಾರ್ಜಿಯನ್ ಭೂ ತೆರಿಗೆ ಮುಂತಾದ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಒಳಗೊಂಡ ವಿಸ್ತೃತ ಚೌಕಟ್ಟನ್ನು ರಚಿಸಿತು. ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್ ಆ ಸಮಯದಲ್ಲಿ ಯಾವುದೇ ಪರಿಣಾಮಕಾರಿ ಪ್ರತಿಕೃತಿ ಡೇಟಾಬೇಸ್ ವ್ಯವಸ್ಥೆ ಲಭ್ಯವಿರಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಎಂದಿಗೂ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅನುಷ್ಠಾನಗೊಳಿಸಲಾಗಲಿಲ್ಲ. ಆದರೆ 2009 ರ ನಂತರ, ಬಿಟ್ಕಾಯಿನ್ನ ವಿಕೇಂದ್ರೀಕೃತ ಸರ್ವಸಮ್ಮತಿ ಅಭಿವೃದ್ಧಿಯಾದ ನಂತರ, ಹಲವಾರು ಪರ್ಯಾಯ ಅನ್ವಯಗಳು ಶೀಘ್ರವಾಗಿ ಹೊರಹೊಮ್ಮಲು ಪ್ರಾರಂಭಿಸಿದವು.
- ನೇಮ್ಕಾಯಿನ್ - 2010 ರಲ್ಲಿ ರಚಿಸಲ್ಪಟ್ಟ ನೇಮ್ಕಾಯಿನ್(opens in a new tab) ಅನ್ನು ವಿಕೇಂದ್ರೀಕೃತ ಹೆಸರು ನೋಂದಣಿ ಡೇಟಾಬೇಸ್ ಎಂದು ಉತ್ತಮವಾಗಿ ವಿವರಿಸಬಹುದು. ಟೋರ್, ಬಿಟ್ಕಾಯಿನ್ ಮತ್ತು ಬಿಟ್ಮೆಸೇಜ್ನಂತಹ ವಿಕೇಂದ್ರೀಕೃತ ಪ್ರೋಟೋಕಾಲ್ಗಳಲ್ಲಿ, ಇತರರು ಅವುಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಖಾತೆಗಳನ್ನು ಗುರುತಿಸುವ ಕೆಲವು ವಿಧಾನಗಳಿರಬೇಕು, ಆದರೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಎಲ್ಲಾ ಪರಿಹಾರಗಳಲ್ಲಿ ಲಭ್ಯವಿರುವ ಏಕೈಕ ಗುರುತಿಸುವಿಕೆಯು
1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy
ನಂತಹ ಸ್ಯೂಡೋರಾಂಡಮ್ ಹ್ಯಾಷ್ ಆಗಿದೆ. ಆದರ್ಶವಾಗಿ, ಒಬ್ಬರು "george" ನಂತಹ ಹೆಸರಿನ ಖಾತೆಯನ್ನು ಹೊಂದಲು ಬಯಸುತ್ತಾರೆ. ಆದರೆ, ಸಮಸ್ಯೆಯೆಂದರೆ ಒಬ್ಬ ವ್ಯಕ್ತಿಯು "george" ಎಂಬ ಹೆಸರಿನ ಖಾತೆಯನ್ನು ರಚಿಸಬಹುದಾದರೆ, ಬೇರೊಬ್ಬರು ಅದೇ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬಳಸಿ ತಮಗಾಗಿ "george" ಅನ್ನು ನೋಂದಾಯಿಸಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅವರನ್ನು ನಕಲಿಸಬಹುದು. ಏಕೈಕ ಪರಿಹಾರವೆಂದರೆ ಮೊದಲು-ಫೈಲ್-ಮಾಡಿದವರ ಮಾದರಿ, ಅಲ್ಲಿ ಮೊದಲ ನೋಂದಣಿದಾರ ಯಶಸ್ವಿಯಾಗುತ್ತಾನೆ ಮತ್ತು ಎರಡನೆಯವನು ವಿಫಲನಾಗುತ್ತಾನೆ - ಇದು ಬಿಟ್ಕಾಯಿನ್ ಸರ್ವಸಮ್ಮತಿ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಸರಿಯಾಗಿ ಹೊಂದುವ ಸಮಸ್ಯೆಯಾಗಿದೆ. ನೇಮ್ಕಾಯಿನ್ ಅಂತಹ ಕಲ್ಪನೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಹೆಸರು ನೋಂದಣಿ ವ್ಯವಸ್ಥೆಯ ಅತ್ಯಂತ ಹಳೆಯ ಮತ್ತು ಅತ್ಯಂತ ಯಶಸ್ವಿ ಅನುಷ್ಠಾನವಾಗಿದೆ. - ಬಣ್ಣದ ನಾಣ್ಯಗಳು - ಬಣ್ಣದ ನಾಣ್ಯಗಳ(opens in a new tab) ಉದ್ದೇಶವೆಂದರೆ ಜನರು ತಮ್ಮದೇ ಆದ ಡಿಜಿಟಲ್ ಕರೆನ್ಸಿಗಳನ್ನು ರಚಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುವ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದು - ಅಥವಾ, ಒಂದು ಘಟಕವನ್ನು ಹೊಂದಿರುವ ಕರೆನ್ಸಿಯ ಮಹತ್ವದ ಕ್ಷುಲ್ಲಕ ಸಂದರ್ಭದಲ್ಲಿ, ಬಿಟ್ಕಾಯಿನ್ ಬ್ಲಾಕ್ಚೈನ್ನಲ್ಲಿ ಡಿಜಿಟಲ್ ಟೋಕನ್ಗಳನ್ನು ರಚಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುವುದು. ಬಣ್ಣದ ನಾಣ್ಯಗಳ ಪ್ರೋಟೋಕಾಲ್ನಲ್ಲಿ, ಒಬ್ಬರು ನಿರ್ದಿಷ್ಟ ಬಿಟ್ಕಾಯಿನ್ UTXO ಗೆ ಸಾರ್ವಜನಿಕವಾಗಿ ಒಂದು ಬಣ್ಣವನ್ನು ನಿಯೋಜಿಸುವ ಮೂಲಕ ಹೊಸ ಕರೆನ್ಸಿಯನ್ನು "ವಿತರಿಸುತ್ತಾರೆ", ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಪುನರಾವರ್ತಕವಾಗಿ ಇತರ UTXO ಗಳ ಬಣ್ಣವನ್ನು ಅವುಗಳನ್ನು ರಚಿಸಿದ ವ್ಯವಹಾರದಲ್ಲಿ ಖರ್ಚು ಮಾಡಲಾದ ಇನ್ಪುಟ್ಗಳ ಬಣ್ಣಕ್ಕೆ ಸಮಾನವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ (ಮಿಶ್ರ-ಬಣ್ಣದ ಇನ್ಪುಟ್ಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಕೆಲವು ವಿಶೇಷ ನಿಯಮಗಳು ಅನ್ವಯಿಸುತ್ತವೆ). ಇದು ಬಳಕೆದಾರರಿಗೆ ನಿರ್ದಿಷ್ಟ ಬಣ್ಣದ UTXO ಗಳನ್ನು ಮಾತ್ರ ಹೊಂದಿರುವ ವಾಲೆಟ್ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ಸಾಮಾನ್ಯ ಬಿಟ್ಕಾಯಿನ್ಗಳಂತೆ ಸುತ್ತಲೂ ಕಳುಹಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಅವರು ಸ್ವೀಕರಿಸುವ ಯಾವುದೇ UTXO ನ ಬಣ್ಣವನ್ನು ನಿರ್ಧರಿಸಲು ಬ್ಲಾಕ್ಚೈನ್ ಮೂಲಕ ಹಿಂದಕ್ಕೆ ಅನುಸರಿಸುತ್ತಾರೆ.
- ಮೆಟಾಕಾಯಿನ್ಗಳು - ಮೆಟಾಕಾಯಿನ್ನ ಹಿಂದಿನ ಆಲೋಚನೆಯೆಂದರೆ ಬಿಟ್ಕಾಯಿನ್ ಮೇಲೆ ಅನ್ವಯಿಸುವ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹೊಂದುವುದು, ಮೆಟಾಕಾಯಿನ್ ವ್ಯವಹಾರಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಿಟ್ಕಾಯಿನ್ ವ್ಯವಹಾರಗಳನ್ನು ಬಳಸುವುದು ಆದರೆ ಭಿನ್ನ ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕ್ರಿಯೆಯನ್ನು ಹೊಂದಿರುವುದು,
APPLY'
. ಮೆಟಾಕಾಯಿನ್ ಪ್ರೋಟೋಕಾಲ್ ಅಮಾನ್ಯ ಮೆಟಾಕಾಯಿನ್ ವ್ಯವಹಾರಗಳು ಬಿಟ್ಕಾಯಿನ್ ಬ್ಲಾಕ್ಚೈನ್ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವುದನ್ನು ತಡೆಯಲಾಗದ ಕಾರಣ,APPLY'(S,TX)
ದೋಷವನ್ನು ತೋರಿಸಿದರೆ, ಪ್ರೋಟೋಕಾಲ್APPLY'(S,TX)
= S ಗೆ ಡೀಫಾಲ್ಟ್ ಆಗುತ್ತದೆ ಎಂಬ ನಿಯಮವನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ. ಇದು ಯಾವುದೇ ಸ್ವೇಚ್ಛಾನುಸಾರ ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸಲು ಸುಲಭ ಕಾರ್ಯವಿಧಾನವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಸಂಭವನೀಯವಾಗಿ ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿ ಅನುಷ್ಠಾನಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದ ಸುಧಾರಿತ ವೈಶಿಷ್ಟ್ಯಗಳೊಂದಿಗೆ, ಆದರೆ ಗಣಿಗಾರಿಕೆ ಮತ್ತು ನೆಟ್ವರ್ಕಿಂಗ್ನ ಸಂಕೀರ್ಣತೆಗಳನ್ನು ಈಗಾಗಲೇ ಬಿಟ್ಕಾಯಿನ್ ಪ್ರೋಟೋಕಾಲ್ ನಿರ್ವಹಿಸುತ್ತಿರುವುದರಿಂದ ಅತ್ಯಂತ ಕಡಿಮೆ ಅಭಿವೃದ್ಧಿ ವೆಚ್ಚದೊಂದಿಗೆ ಲಭ್ಯವಿದೆ. ಮೆಟಾಕಾಯಿನ್ಗಳನ್ನು ಕೆಲವು ವರ್ಗಗಳ ಹಣಕಾಸು ಒಪ್ಪಂದಗಳು, ಹೆಸರು ನೋಂದಣಿ ಮತ್ತು ವಿಕೇಂದ್ರೀಕೃತ ವಿನಿಮಯವನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಲು ಬಳಸಲಾಗಿದೆ.
ಹೀಗಾಗಿ, ಸಾಮಾನ್ಯವಾಗಿ, ಸರ್ವಸಮ್ಮತಿ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಎರಡು ವಿಧಾನಗಳಿವೆ: ಸ್ವತಂತ್ರ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಮತ್ತು ಬಿಟ್ಕಾಯಿನ್ ಮೇಲೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ತಯಾರಿಸುವುದು. ಮೊದಲನೆಯ ವಿಧಾನವು, ನೇಮ್ಕಾಯಿನ್ನಂತಹ ಅಪ್ಲಿಕೇಶನ್ಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಸಾಕಷ್ಟು ಯಶಸ್ವಿಯಾಗಿದ್ದರೂ, ಅನುಷ್ಠಾನಗೊಳಿಸಲು ಕಷ್ಟಕರವಾಗಿದೆ; ಪ್ರತಿಯೊಂದು ವೈಯಕ್ತಿಕ ಅನುಷ್ಠಾನವು ಸ್ವತಂತ್ರ ಬ್ಲಾಕ್ಚೈನ್ ಅನ್ನು ಹೆಚ್ಚು ನೆರವು ಸಿಗದೆ ಸ್ವಯಂ ಆಗಿ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಜೊತೆಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಮತ್ತು ನೆಟ್ವರ್ಕಿಂಗ್ ಕೋಡ್ ಅನ್ನು ನಿರ್ಮಿಸಿ ಪರೀಕ್ಷಿಸಬೇಕಾಗುತ್ತದೆ. ಇದಲ್ಲದೆ, ವಿಕೇಂದ್ರೀಕೃತ ಒಮ್ಮತ ತಂತ್ರಜ್ಞಾನಕ್ಕಾಗಿ ಅಪ್ಲಿಕೇಶನ್ಗಳ ಸಮೂಹವು ಪವರ್ ಲಾ ಅಂದರೆ, ಒಂದರಲ್ಲಿ ಆದ ಬದಲಾವಣೆ ಮತ್ತೊಂದಕ್ಕೂ ಅನ್ವಯಿಸುವುದು, ವಿತರಣೆಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ ಎಂದು ನಾವು ಭವಿಷ್ಯ ನುಡಿಯುತ್ತೇವೆ, ಇಲ್ಲಿ ಬಹುಪಾಲು ಅಪ್ಲಿಕೇಶನ್ಗಳು ತಮ್ಮದೇ ಆದ ಬ್ಲಾಕ್ಚೈನ್ ಅನ್ನು ಹೊಂದಲು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿರುತ್ತವೆ, ಮತ್ತು ವಿಕೇಂದ್ರೀಕೃತ ಅಪ್ಲಿಕೇಶನ್ಗಳ ದೊಡ್ಡ ವರ್ಗಗಳು, ವಿಶೇಷವಾಗಿ ವಿಕೇಂದ್ರೀಕೃತ ಸ್ವಾಯತ್ತ ಸಂಸ್ಥೆಗಳು, ಒಂದಕ್ಕೊಂದು ಸಂವಹನ ನಡೆಸಬೇಕಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಗಮನಿಸುತ್ತೇವೆ.
ಮತ್ತೊಂದೆಡೆ, ಬಿಟ್ಕಾಯಿನ್ ಆಧಾರಿತ ವಿಧಾನವು ಬಿಟ್ಕಾಯಿನ್ನ ಸರಳೀಕೃತ ಪಾವತಿ ಪರಿಶೀಲನೆ (SPV) ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಪಡೆಯುವುದಿಲ್ಲ ಎಂಬ ದೋಷವನ್ನು ಹೊಂದಿದೆ. SPV ಬಿಟ್ಕಾಯಿನ್ಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ಮಾನ್ಯತೆಗಾಗಿ ಬ್ಲಾಕ್ಚೈನ್ ಆಳವನ್ನು ಪ್ರಾಕ್ಸಿಯಾಗಿ ಬಳಸಬಹುದು; ಒಂದು ಹಂತದಲ್ಲಿ, ಒಮ್ಮೆ ವಹಿವಾಟಿನ ಪೂರ್ವಜರು ಸಾಕಷ್ಟು ಹಿಂದೆ ಹೋದರೆ, ಅವು ನಿಜವಾಗಿಯೂ ಸ್ಥಿತಿಯ ಭಾಗವಾಗಿದ್ದವು ಎಂದು ಹೇಳುವುದು ಸುರಕ್ಷಿತ. ಮತ್ತೊಂದೆಡೆ, ಬ್ಲಾಕ್ಚೈನ್ ಆಧಾರಿತ ಮೆಟಾ-ಪ್ರೊಟೋಕಾಲ್ಗಳು ಅವುಗಳ ಸ್ವಂತ ಪ್ರೊಟೋಕಾಲ್ಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಅಮಾನ್ಯವಾಗಿರುವ ವಹಿವಾಟುಗಳನ್ನು ಸೇರಿಸದಂತೆ ಬ್ಲಾಕ್ಚೈನ್ ಅನ್ನು ಒತ್ತಾಯಿಸಲಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಸಂಪೂರ್ಣವಾಗಿ ಸುರಕ್ಷಿತ SPV ಮೆಟಾ-ಪ್ರೊಟೋಕಾಲ್ ಅನುಷ್ಠಾನವು ನಿರ್ದಿಷ್ಟ ವಹಿವಾಟುಗಳು ಮಾನ್ಯವಾಗಿವೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಲು ಬಿಟ್ಕಾಯಿನ್ ಬ್ಲಾಕ್ಚೈನ್ನ ಆರಂಭದವರೆಗೆ ಹಿಂದಕ್ಕೆ ಸ್ಕ್ಯಾನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಪ್ರಸ್ತುತ, ಬಿಟ್ಕಾಯಿನ್ ಆಧಾರಿತ ಮೆಟಾ-ಪ್ರೊಟೋಕಾಲ್ಗಳ ಎಲ್ಲಾ "ಹಗುರ" ಅನುಷ್ಠಾನಗಳು ಡೇಟಾವನ್ನು ಒದಗಿಸಲು ವಿಶ್ವಾಸಾರ್ಹ ಸರ್ವರ್ ಅನ್ನು ಅವಲಂಬಿಸುತ್ತವೆ, ಇದು ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿಯ ಪ್ರಾಥಮಿಕ ಉದ್ದೇಶಗಳಲ್ಲಿ ಒಂದು ವಿಶ್ವಾಸದ ಅಗತ್ಯವನ್ನು ತೊಡೆದುಹಾಕುವುದಾಗಿದ್ದಾಗ ಇದು ಖಂಡಿತವಾಗಿಯೂ ಅತ್ಯಂತ ಅಸಮರ್ಪಕ ಫಲಿತಾಂಶವಾಗಿದೆ.
ಸ್ಕ್ರಿಪ್ಟಿಂಗ್
ಯಾವುದೇ ವಿಸ್ತರಣೆಗಳಿಲ್ಲದೆಯೇ, ಬಿಟ್ಕಾಯಿನ್ ಪ್ರೊಟೋಕಾಲ್ ವಾಸ್ತವವಾಗಿ "ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದಗಳ" ಪರಿಕಲ್ಪನೆಯ ದುರ್ಬಲ ಆವೃತ್ತಿಯನ್ನು ಸುಗಮಗೊಳಿಸುತ್ತದೆ. ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿನ UTXO ಕೇವಲ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯಿಂದ ಮಾತ್ರವಲ್ಲದೆ, ಸರಳ ಸ್ಟ್ಯಾಕ್-ಆಧಾರಿತ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಲ್ಲಿ ವ್ಯಕ್ತಪಡಿಸಲಾದ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಸ್ಕ್ರಿಪ್ಟ್ನಿಂದಲೂ ಮಾಲೀಕತ್ವ ಹೊಂದಬಹುದು. ಈ ಮಾದರಿಯಲ್ಲಿ, ಆ UTXO ಅನ್ನು ಖರ್ಚು ಮಾಡುವ ವಹಿವಾಟು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ತೃಪ್ತಿಪಡಿಸುವ ಡೇಟಾವನ್ನು ಒದಗಿಸಬೇಕು. ವಾಸ್ತವವಾಗಿ, ಮೂಲಭೂತ ಸಾರ್ವಜನಿಕ ಕೀಲಿ ಮಾಲೀಕತ್ವ ಕಾರ್ಯವಿಧಾನವನ್ನು ಸಹ ಸ್ಕ್ರಿಪ್ಟ್ ಮೂಲಕ ಅನುಷ್ಠಾನಗೊಳಿಸಲಾಗಿದೆ: ಸ್ಕ್ರಿಪ್ಟ್ ಎಲಿಪ್ಟಿಕ್ ಕರ್ವ್ ಸಹಿಯನ್ನು ಇನ್ಪುಟ್ ಆಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಅದನ್ನು ವಹಿವಾಟು ಮತ್ತು UTXO ಅನ್ನು ಮಾಲೀಕತ್ವ ಹೊಂದಿರುವ ವಿಳಾಸದೊಂದಿಗೆ ಪರಿಶೀಲಿಸುತ್ತದೆ, ಮತ್ತು ಪರಿಶೀಲನೆ ಯಶಸ್ವಿಯಾದರೆ 1 ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಇಲ್ಲದಿದ್ದರೆ 0 ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ವಿವಿಧ ಹೆಚ್ಚುವರಿ ಬಳಕೆಯ ಪ್ರಕರಣಗಳಿಗಾಗಿ ಇತರ, ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ಉದಾಹರಣೆಗೆ, ಮಾನ್ಯತೆಗೊಳಿಸಲು ನೀಡಲಾದ ಮೂರು ಖಾಸಗಿ ಕೀಲಿಗಳಲ್ಲಿ ಎರಡರಿಂದ ಸಹಿಗಳನ್ನು ಅಗತ್ಯಪಡಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ನಿರ್ಮಿಸಬಹುದು ("ಮಲ್ಟಿಸಿಗ್"), ಇದು ಕಾರ್ಪೊರೇಟ್ ಖಾತೆಗಳು, ಸುರಕ್ಷಿತ ಉಳಿತಾಯ ಖಾತೆಗಳು ಮತ್ತು ಕೆಲವು ವ್ಯಾಪಾರಿ ಎಸ್ಕ್ರೋ ಸಂದರ್ಭಗಳಿಗೆ ಉಪಯುಕ್ತವಾದ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ಗಣನಾ ಸಮಸ್ಯೆಗಳ ಪರಿಹಾರಗಳಿಗೆ ಬಹುಮಾನ ನೀಡಲು ಸಹ ಬಳಸಬಹುದು, ಮತ್ತು "ನೀವು ನನಗೆ ಈ ಮೌಲ್ಯದ ಡೋಜ್ಕಾಯಿನ್ ವಹಿವಾಟನ್ನು ಕಳುಹಿಸಿದ್ದೀರಿ ಎಂಬುದಕ್ಕೆ SPV ಪುರಾವೆಯನ್ನು ಒದಗಿಸಬಲ್ಲಿರಿ ಎಂದರೆ ಈ ಬಿಟ್ಕಾಯಿನ್ UTXO ನಿಮ್ಮದು" ಎಂದು ಹೇಳುವ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸಹ ರಚಿಸಬಹುದು, ಇದು ಮೂಲತಃ ವಿಕೇಂದ್ರೀಕೃತ ಕ್ರಾಸ್-ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿ ವಿನಿಮಯವನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
ಆದಾಗ್ಯೂ, ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿ ಅನುಷ್ಠಾನಗೊಳಿಸಲಾದ ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಭಾಷೆಯು ಹಲವಾರು ಮುಖ್ಯ ಮಿತಿಗಳನ್ನು ಹೊಂದಿದೆ:
- ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣತೆಯ ಕೊರತೆ - ಅಂದರೆ, ಬಿಟ್ಕಾಯಿನ್ ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಭಾಷೆಯು ಬೆಂಬಲಿಸುವ ಗಣನೆಯ ದೊಡ್ಡ ಉಪಗುಂಪು ಇದ್ದರೂ, ಅದು ಎಲ್ಲವನ್ನೂ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಕಾಣೆಯಾಗಿರುವ ಮುಖ್ಯ ವರ್ಗವೆಂದರೆ ಲೂಪ್ಗಳು. ವಹಿವಾಟು ಪರಿಶೀಲನೆಯ ಸಮಯದಲ್ಲಿ ಅನಂತ ಲೂಪ್ಗಳನ್ನು ತಪ್ಪಿಸಲು ಇದನ್ನು ಮಾಡಲಾಗಿದೆ; ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಇದು ಸ್ಕ್ರಿಪ್ಟ್ ಪ್ರೋಗ್ರಾಮರ್ಗಳಿಗೆ ಅಧಿಗಮಿಸಬಹುದಾದ ತಡೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಯಾವುದೇ ಲೂಪ್ ಅನ್ನು ಕೇವಲ ಅಂತರ್ನಿಹಿತ ಕೋಡ್ ಅನ್ನು if ಹೇಳಿಕೆಯೊಂದಿಗೆ ಹಲವಾರು ಬಾರಿ ಪುನರಾವರ್ತಿಸುವ ಮೂಲಕ ಅನುಕರಿಸಬಹುದು, ಆದರೆ ಇದು ಬಹಳ ಸ್ಥಳ-ಅಸಮರ್ಥ ಸ್ಕ್ರಿಪ್ಟ್ಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಪರ್ಯಾಯ ಎಲಿಪ್ಟಿಕ್ ಕರ್ವ್ ಸಹಿ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಲು 256 ಪುನರಾವರ್ತಿತ ಗುಣಾಕಾರ ಸುತ್ತುಗಳು ಬೇಕಾಗಬಹುದು, ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಕೋಡ್ನಲ್ಲಿ ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ.
- ಮೌಲ್ಯ-ಅಂಧತ್ವ - ಹಿಂಪಡೆಯಬಹುದಾದ ಮೊತ್ತದ ಮೇಲೆ ಸೂಕ್ಷ್ಮ ನಿಯಂತ್ರಣವನ್ನು ಒದಗಿಸಲು UTXO ಸ್ಕ್ರಿಪ್ಟ್ಗೆ ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಒರಾಕಲ್ ಒಪ್ಪಂದದ ಒಂದು ಶಕ್ತಿಶಾಲಿ ಬಳಕೆಯ ಪ್ರಕರಣವೆಂದರೆ ಹೆಡ್ಜಿಂಗ್ ಒಪ್ಪಂದ, ಇಲ್ಲಿ A ಮತ್ತು B $1000 ಮೌಲ್ಯದ BTC ಹಾಕುತ್ತಾರೆ ಮತ್ತು 30 ದಿನಗಳ ನಂತರ ಸ್ಕ್ರಿಪ್ಟ್ $1000 ಮೌಲ್ಯದ BTC ಅನ್ನು A ಗೆ ಮತ್ತು ಉಳಿದದ್ದನ್ನು B ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಇದಕ್ಕೆ USD ನಲ್ಲಿ 1 BTC ನ ಮೌಲ್ಯವನ್ನು ನಿರ್ಧರಿಸಲು ಒರಾಕಲ್ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದರೂ ಇದು ವಿಶ್ವಾಸ ಮತ್ತು ಮೂಲಸೌಕರ್ಯದ ಅಗತ್ಯತೆಯ ದೃಷ್ಟಿಯಿಂದ ಪ್ರಸ್ತುತ ಲಭ್ಯವಿರುವ ಸಂಪೂರ್ಣ ಕೇಂದ್ರೀಕೃತ ಪರಿಹಾರಗಳಿಗಿಂತ ಭಾರೀ ಸುಧಾರಣೆಯಾಗಿದೆ. ಆದರೆ, UTXO ಗಳು ಸಂಪೂರ್ಣ-ಅಥವಾ-ಏನೂ ಇಲ್ಲ ಎಂಬ ರೀತಿಯಲ್ಲಿರುವುದರಿಂದ, ಇದನ್ನು ಸಾಧಿಸಲು ಒಂದೇ ಮಾರ್ಗವೆಂದರೆ ವಿವಿಧ ಮೌಲ್ಯಗಳ ಅನೇಕ UTXO ಗಳನ್ನು ಹೊಂದುವುದು (ಉದಾ. 30 ವರೆಗಿನ ಪ್ರತಿ k ಗೆ 2k ನ ಒಂದು UTXO) ಮತ್ತು ಒರಾಕಲ್ ಯಾವ UTXO ಅನ್ನು A ಗೆ ಮತ್ತು ಯಾವುದನ್ನು B ಗೆ ಕಳುಹಿಸಬೇಕೆಂದು ಆಯ್ಕೆ ಮಾಡುವುದು - ಇದು ಬಹಳ ಅಸಮರ್ಪಕ ವಿಧಾನವಾಗಿದೆ.
- ಸ್ಥಿತಿಯ ಕೊರತೆ - UTXO ಗಳನ್ನು ಖರ್ಚು ಮಾಡಬಹುದು ಅಥವಾ ಖರ್ಚು ಮಾಡದೆ ಇರಬಹುದು; ಬಹು-ಹಂತದ ಒಪ್ಪಂದಗಳಿಗೆ ಅಥವಾ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಆಂತರಿಕ ಸ್ಥಿತಿಯನ್ನು ಇರಿಸಿಕೊಳ್ಳುವ ಸ್ಕ್ರಿಪ್ಟ್ಗಳಿಗೆ ಯಾವುದೇ ಅವಕಾಶವಿಲ್ಲ. ಇದು ಬಹು-ಹಂತದ ಆಯ್ಕೆ ಒಪ್ಪಂದಗಳು, ವಿಕೇಂದ್ರೀಕೃತ ವಿನಿಮಯ ಕೊಡುಗೆಗಳು ಅಥವಾ ಎರಡು-ಹಂತದ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಬದ್ಧತೆ ಪ್ರೊಟೋಕಾಲ್ಗಳನ್ನು (ಸುರಕ್ಷಿತ ಗಣನಾ ಬಹುಮಾನಗಳಿಗೆ ಅಗತ್ಯವಿರುವ) ರಚಿಸಲು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ. ಇದು UTXO ಗಳನ್ನು ಕೇವಲ ಸರಳ, ಒಂದೇ ಬಾರಿಯ ಒಪ್ಪಂದಗಳನ್ನು ನಿರ್ಮಿಸಲು ಮಾತ್ರ ಬಳಸಬಹುದು ಎಂದು ಅರ್ಥ ಮತ್ತು ವಿಕೇಂದ್ರೀಕೃತ ಸಂಸ್ಥೆಗಳಂತಹ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ "ಸ್ಥಿತಿಯುಕ್ತ" ಒಪ್ಪಂದಗಳನ್ನು ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಮೆಟಾ-ಪ್ರೊಟೋಕಾಲ್ಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಲು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ. ಮೌಲ್ಯ-ಅಂಧತ್ವದೊಂದಿಗೆ ಸಂಯೋಜಿತ ದ್ವಿಮಾನ ಸ್ಥಿತಿಯು ಮತ್ತೊಂದು ಮುಖ್ಯ ಅಪ್ಲಿಕೇಶನ್, ಹಿಂಪಡೆಯುವಿಕೆ ಮಿತಿಗಳನ್ನು ಅಸಾಧ್ಯಗೊಳಿಸುತ್ತದೆ.
- ಬ್ಲಾಕ್ಚೈನ್-ಅಂಧತ್ವ - UTXO ಗಳು ನಾನ್ಸ್, ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಮತ್ತು ಹಿಂದಿನ ಬ್ಲಾಕ್ ಹ್ಯಾಷ್ ಮುಂತಾದ ಬ್ಲಾಕ್ಚೈನ್ ಡೇಟಾಗೆ ಕುರುಡಾಗಿವೆ. ಇದು ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಭಾಷೆಯನ್ನು ಯಾದೃಚ್ಛಿಕತೆಯ ಸಂಭಾವ್ಯ ಮೌಲ್ಯಯುತ ಮೂಲದಿಂದ ವಂಚಿಸುವ ಮೂಲಕ ಜೂಜು ಮತ್ತು ಹಲವಾರು ಇತರ ವರ್ಗಗಳಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ತೀವ್ರವಾಗಿ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ.
ಹೀಗೆ, ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿಯ ಮೇಲೆ ಅತ್ಯಾಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಮೂರು ವಿಧಾನಗಳನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ: ಹೊಸ ಬ್ಲಾಕ್ಚೈನ್ ನಿರ್ಮಿಸುವುದು, ಬಿಟ್ಕಾಯಿನ್ ಮೇಲೆ ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಬಳಸುವುದು, ಮತ್ತು ಬಿಟ್ಕಾಯಿನ್ ಮೇಲೆ ಮೆಟಾ-ಪ್ರೋಟೋಕಾಲ್ ನಿರ್ಮಿಸುವುದು. ಹೊಸ ಬ್ಲಾಕ್ಚೈನ್ ನಿರ್ಮಿಸುವುದು, ವೈಶಿಷ್ಟ್ಯ ಸೆಟ್ ನಿರ್ಮಿಸುವಲ್ಲಿ ಅಪರಿಮಿತ ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಅಭಿವೃದ್ಧಿ ಸಮಯ, ಬೂಟ್ಸ್ಟ್ರಾಪಿಂಗ್ ಪ್ರಯತ್ನ ಮತ್ತು ಭದ್ರತೆಯ ವೆಚ್ಚ ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ. ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಬಳಸುವುದು ಅನುಷ್ಠಾನಗೊಳಿಸಲು ಮತ್ತು ಪ್ರಮಾಣೀಕರಿಸಲು ಸುಲಭವಾಗಿದೆ, ಆದರೆ ಅದರ ಸಾಮರ್ಥ್ಯಗಳಲ್ಲಿ ಬಹಳ ಸೀಮಿತವಾಗಿದೆ, ಮತ್ತು ಮೆಟಾ-ಪ್ರೋಟೋಕಾಲ್ಗಳು, ಸುಲಭವಾಗಿದ್ದರೂ, ಸ್ಕೇಲೇಬಿಲಿಟಿಯಲ್ಲಿ ದೋಷಗಳನ್ನು ಎದುರಿಸುತ್ತವೆ. ಎಥೆರಿಯಮ್ನೊಂದಿಗೆ, ನಾವು ಅಭಿವೃದ್ಧಿಯ ಸುಲಭತೆಯಲ್ಲಿ ಇನ್ನೂ ದೊಡ್ಡ ಲಾಭಗಳನ್ನು ಒದಗಿಸುವ ಹಾಗೂ ಇನ್ನೂ ಬಲವಾದ ಲೈಟ್ ಕ್ಲೈಂಟ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರುವ ಪರ್ಯಾಯ ಚೌಕಟ್ಟನ್ನು ನಿರ್ಮಿಸಲು ಉದ್ದೇಶಿಸಿದ್ದೇವೆ, ಅದೇ ಸಮಯದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಆರ್ಥಿಕ ಪರಿಸರ ಮತ್ತು ಬ್ಲಾಕ್ಚೈನ್ ಭದ್ರತೆಯನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಅನುಮತಿಸುತ್ತದೆ.
ಇಥಿರಿಯಮ್
ಎಥೆರಿಯಮ್ನ ಉದ್ದೇಶವು ವಿಕೇಂದ್ರೀಕೃತ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಪರ್ಯಾಯ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸುವುದಾಗಿದೆ, ವಿಭಿನ್ನ ಟ್ರೇಡ್ಆಫ್ಗಳ ಗುಂಪನ್ನು ಒದಗಿಸುವುದು, ಇದು ವಿಕೇಂದ್ರೀಕೃತ ಅಪ್ಲಿಕೇಶನ್ಗಳ ದೊಡ್ಡ ವರ್ಗಕ್ಕೆ ಬಹಳ ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ ಎಂದು ನಾವು ನಂಬುತ್ತೇವೆ, ವಿಶೇಷವಾಗಿ ವೇಗದ ಅಭಿವೃದ್ಧಿ ಸಮಯ, ಸಣ್ಣ ಮತ್ತು ಅಪರೂಪವಾಗಿ ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ ಭದ್ರತೆ, ಮತ್ತು ವಿಭಿನ್ನ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಬಹಳ ದಕ್ಷತೆಯಿಂದ ಸಂವಹನ ನಡೆಸುವ ಸಾಮರ್ಥ್ಯ ಮುಖ್ಯವಾಗಿರುವ ಸಂದರ್ಭಗಳ ಮೇಲೆ ವಿಶೇಷ ಒತ್ತು ನೀಡುತ್ತದೆ. ಎಥೆರಿಯಮ್ ಇದನ್ನು ಅತ್ಯಂತ ಅಮೂರ್ತ ಮೂಲಭೂತ ಪದರವನ್ನು ನಿರ್ಮಿಸುವ ಮೂಲಕ ಮಾಡುತ್ತದೆ: ಅಂತರ್ನಿರ್ಮಿತ ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯೊಂದಿಗಿನ ಬ್ಲಾಕ್ಚೈನ್, ಯಾರಾದರೂ ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದಗಳನ್ನು ಮತ್ತು ವಿಕೇಂದ್ರೀಕೃತ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಬರೆಯಲು ಅನುಮತಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಅವರು ಮಾಲೀಕತ್ವ, ವ್ಯವಹಾರ ಸ್ವರೂಪಗಳು ಮತ್ತು ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯಗಳಿಗಾಗಿ ತಮ್ಮದೇ ಆದ ಸ್ವೇಚ್ಛಾನುಸಾರ ನಿಯಮಗಳನ್ನು ರಚಿಸಬಹುದು. ನೇಮ್ಕಾಯಿನ್ನ ಮೂಲ ಆವೃತ್ತಿಯನ್ನು ಎರಡು ಸಾಲುಗಳ ಕೋಡ್ನಲ್ಲಿ ಬರೆಯಬಹುದು, ಮತ್ತು ಕರೆನ್ಸಿಗಳು ಮತ್ತು ಖ್ಯಾತಿ ವ್ಯವಸ್ಥೆಗಳಂತಹ ಇತರ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಇಪ್ಪತ್ತು ಸಾಲುಗಳಿಗಿಂತ ಕಡಿಮೆ ಕೋಡ್ನಲ್ಲಿ ನಿರ್ಮಿಸಬಹುದು. ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದಗಳು, ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುವ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸಿದರೆ ಮಾತ್ರ ಅದನ್ನು ಅನ್ಲಾಕ್ ಮಾಡುವ ಗೂಢಲಿಪೀಕರಣ "ಪೆಟ್ಟಿಗೆಗಳು", ಈ ವೇದಿಕೆಯ ಮೇಲೆ ನಿರ್ಮಿಸಬಹುದು, ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣತೆ, ಮೌಲ್ಯ-ಜಾಗೃತಿ, ಬ್ಲಾಕ್ಚೈನ್-ಜಾಗೃತಿ ಮತ್ತು ಸ್ಥಿತಿಯ ಹೆಚ್ಚುವರಿ ಶಕ್ತಿಗಳಿಂದಾಗಿ ಬಿಟ್ಕಾಯಿನ್ ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ನೀಡುವುದಕ್ಕಿಂತ ವ್ಯಾಪಕವಾಗಿ ಹೆಚ್ಚಿನ ಶಕ್ತಿಯೊಂದಿಗೆ.
ಎಥೆರಿಯಮ್ ಖಾತೆಗಳು
ಎಥೆರಿಯಮ್ನಲ್ಲಿ, ಸ್ಥಿತಿಯು "ಖಾತೆಗಳು" ಎಂಬ ವಸ್ತುಗಳಿಂದ ಮಾಡಲ್ಪಟ್ಟಿದೆ, ಪ್ರತಿ ಖಾತೆಯು 20-ಬೈಟ್ ವಿಳಾಸವನ್ನು ಹೊಂದಿದ್ದು ಮತ್ತು ಸ್ಥಿತಿ ಪರಿವರ್ತನೆಗಳು ಖಾತೆಗಳ ನಡುವೆ ಮೌಲ್ಯ ಮತ್ತು ಮಾಹಿತಿಯ ನೇರ ವರ್ಗಾವಣೆಗಳಾಗಿವೆ. ಎಥೆರಿಯಮ್ ಖಾತೆಯು ನಾಲ್ಕು ಕ್ಷೇತ್ರಗಳನ್ನು ಹೊಂದಿದೆ:
- ನಾನ್ಸ್, ಪ್ರತಿ ವ್ಯವಹಾರವನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಬಳಸುವ ಕೌಂಟರ್
- ಖಾತೆಯ ಪ್ರಸ್ತುತ ಎಥೆರ್ ಬ್ಯಾಲೆನ್ಸ್
- ಖಾತೆಯ ಒಪ್ಪಂದ ಕೋಡ್, ಇದ್ದರೆ
- ಖಾತೆಯ ಸಂಗ್ರಹಣೆ (ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಖಾಲಿ)
"ಎಥೆರ್" ಎಥೆರಿಯಮ್ನ ಮುಖ್ಯ ಆಂತರಿಕ ಕ್ರಿಪ್ಟೋ-ಇಂಧನವಾಗಿದೆ, ಮತ್ತು ವ್ಯವಹಾರ ಶುಲ್ಕಗಳನ್ನು ಪಾವತಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಎರಡು ರೀತಿಯ ಖಾತೆಗಳಿವೆ: ಖಾಸಗಿ ಕೀಗಳಿಂದ ನಿಯಂತ್ರಿಸಲ್ಪಡುವ ಬಾಹ್ಯ ಮಾಲೀಕತ್ವದ ಖಾತೆಗಳು, ಮತ್ತು ಅವುಗಳ ಒಪ್ಪಂದ ಕೋಡ್ನಿಂದ ನಿಯಂತ್ರಿಸಲ್ಪಡುವ ಒಪ್ಪಂದ ಖಾತೆಗಳು. ಬಾಹ್ಯ ಮಾಲೀಕತ್ವದ ಖಾತೆಯು ಯಾವುದೇ ಕೋಡ್ ಹೊಂದಿರುವುದಿಲ್ಲ, ಮತ್ತು ವ್ಯವಹಾರವನ್ನು ರಚಿಸುವ ಮತ್ತು ಸಹಿ ಮಾಡುವ ಮೂಲಕ ಬಾಹ್ಯ ಮಾಲೀಕತ್ವದ ಖಾತೆಯಿಂದ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಬಹುದು; ಒಪ್ಪಂದ ಖಾತೆಯಲ್ಲಿ, ಒಪ್ಪಂದ ಖಾತೆಯು ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸುವ ಪ್ರತಿ ಬಾರಿ ಅದರ ಕೋಡ್ ಸಕ್ರಿಯಗೊಳ್ಳುತ್ತದೆ, ಇದು ಆಂತರಿಕ ಸಂಗ್ರಹಣೆಯನ್ನು ಓದಲು ಮತ್ತು ಬರೆಯಲು ಮತ್ತು ಇತರ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಲು ಅಥವಾ ಬದಲಾಗಿ ಒಪ್ಪಂದಗಳನ್ನು ರಚಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.
ಎಥೆರಿಯಮ್ನಲ್ಲಿ "ಒಪ್ಪಂದಗಳನ್ನು" "ಪೂರೈಸಬೇಕು" ಅಥವಾ "ಅನುಸರಿಸಬೇಕು" ಎಂದು ನೋಡಬಾರದು ಎಂಬುದನ್ನು ಗಮನಿಸಿ; ಬದಲಾಗಿ, ಅವುಗಳನ್ನು ಎಥೆರಿಯಮ್ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಪರಿಸರದಲ್ಲಿ ವಾಸಿಸುವ "ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್ಗಳು" ಎಂದು ಪರಿಗಣಿಸಬೇಕು, ಸಂದೇಶ ಅಥವಾ ವ್ಯವಹಾರದಿಂದ "ಚುಚ್ಚಲ್ಪಟ್ಟಾಗ" ಯಾವಾಗಲೂ ನಿರ್ದಿಷ್ಟ ಕೋಡ್ ತುಣುಕನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳ ಸ್ವಂತ ಎಥೆರ್ ಶಿಲ್ಕು ಮತ್ತು ನಿರಂತರ ವೇರಿಯೇಬಲ್ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಅವುಗಳ ಸ್ವಂತ ಕೀ/ಮೌಲ್ಯ ಸಂಗ್ರಹಣೆಯ ಮೇಲೆ ನೇರ ನಿಯಂತ್ರಣ ಹೊಂದಿರುತ್ತವೆ.
ಸಂದೇಶಗಳು ಮತ್ತು ವ್ಯವಹಾರಗಳು
ಎಥೆರಿಯಮ್ನಲ್ಲಿ "ವ್ಯವಹಾರ" ಎಂಬ ಪದವನ್ನು ಬಾಹ್ಯ ಮಾಲೀಕತ್ವದ ಖಾತೆಯಿಂದ ಕಳುಹಿಸಬೇಕಾದ ಸಂದೇಶವನ್ನು ಸಂಗ್ರಹಿಸುವ ಸಹಿ ಮಾಡಿದ ಡೇಟಾ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸೂಚಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ವ್ಯವಹಾರಗಳು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಒಳಗೊಂಡಿವೆ:
- ಸಂದೇಶ ಸ್ವೀಕರಿಸುವವರು
- ಕಳುಹಿಸುವವರನ್ನು ಗುರುತಿಸುವ ಸಹಿ
- ಕಳುಹಿಸುವವರಿಂದ ಸ್ವೀಕರಿಸುವವರಿಗೆ ವರ್ಗಾಯಿಸಬೇಕಾದ ಎಥೆರ್ ಮೊತ್ತ
- ಐಚ್ಛಿಕ ಡೇಟಾ ಕ್ಷೇತ್ರ
STARTGAS
ಮೌಲ್ಯ, ವ್ಯವಹಾರ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಗೆ ಅನುಮತಿಸಲಾದ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಕಂಪ್ಯುಟೇಶನ್ ಹಂತಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆGASPRICE
ಮೌಲ್ಯ, ಪ್ರತಿ ಕಂಪ್ಯುಟೇಶನ್ ಹಂತಕ್ಕೆ ಕಳುಹಿಸುವವರು ಪಾವತಿಸುವ ಶುಲ್ಕವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ
ಮೊದಲ ಮೂರು ಯಾವುದೇ ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿಯಲ್ಲಿ ನಿರೀಕ್ಷಿಸಲಾದ ಪ್ರಮಾಣಿತ ಕ್ಷೇತ್ರಗಳಾಗಿವೆ. ಡೇಟಾ ಕ್ಷೇತ್ರವು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಯಾವುದೇ ಕಾರ್ಯವನ್ನು ಹೊಂದಿಲ್ಲ, ಆದರೆ ವರ್ಚುವಲ್ ಮಷೀನ್ ಒಂದು ಆಪ್ಕೋಡ್ ಅನ್ನು ಹೊಂದಿದೆ, ಇದರ ಮೂಲಕ ಒಪ್ಪಂದವು ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಬಹುದು; ಉದಾಹರಣೆ ಬಳಕೆಯ ಸಂದರ್ಭವಾಗಿ, ಒಂದು ಒಪ್ಪಂದವು ಬ್ಲಾಕ್ಚೈನ್-ಮೇಲಿನ ಡೊಮೇನ್ ನೋಂದಣಿ ಸೇವೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಅದು ತನಗೆ ರವಾನಿಸಲ್ಪಡುತ್ತಿರುವ ಡೇಟಾವನ್ನು ಎರಡು "ಕ್ಷೇತ್ರಗಳನ್ನು" ಹೊಂದಿರುವುದಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು, ಮೊದಲ ಕ್ಷೇತ್ರವು ನೋಂದಾಯಿಸಬೇಕಾದ ಡೊಮೇನ್ ಆಗಿದ್ದು ಮತ್ತು ಎರಡನೇ ಕ್ಷೇತ್ರವು ಅದನ್ನು ನೋಂದಾಯಿಸಬೇಕಾದ IP ವಿಳಾಸವಾಗಿದೆ. ಒಪ್ಪಂದವು ಈ ಮೌಲ್ಯಗಳನ್ನು ಸಂದೇಶ ಡೇಟಾದಿಂದ ಓದುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಸೂಕ್ತವಾಗಿ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಇರಿಸುತ್ತದೆ.
STARTGAS
ಮತ್ತು GASPRICE
ಕ್ಷೇತ್ರಗಳು ಎಥೆರಿಯಮ್ನ ಸೇವಾ-ನಿರಾಕರಣೆ ವಿರೋಧಿ ಮಾದರಿಗೆ ನಿರ್ಣಾಯಕವಾಗಿವೆ. ಕೋಡ್ನಲ್ಲಿ ಆಕಸ್ಮಿಕ ಅಥವಾ ದುರುದ್ದೇಶಪೂರಿತ ಅನಂತ ಲೂಪ್ಗಳು ಅಥವಾ ಇತರ ಕಂಪ್ಯುಟೇಶನಲ್ ವ್ಯರ್ಥತೆಯನ್ನು ತಡೆಯಲು, ಪ್ರತಿ ವ್ಯವಹಾರವು ಅದು ಬಳಸಬಹುದಾದ ಕೋಡ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಎಷ್ಟು ಕಂಪ್ಯುಟೇಶನಲ್ ಹಂತಗಳಿಗೆ ಮಿತಿಯನ್ನು ಹೊಂದಿಸಬೇಕಾಗಿದೆ. ಗಣನೆಯ ಮೂಲ ಘಟಕವು "ಇಂಧನ" ಆಗಿದೆ; ಸಾಮಾನ್ಯವಾಗಿ, ಕಂಪ್ಯುಟೇಶನಲ್ ಹಂತವು 1 ಇಂಧನ ವೆಚ್ಚ ಮಾಡುತ್ತದೆ, ಆದರೆ ಕೆಲವು ಕಾರ್ಯಾಚರಣೆಗಳು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಇಂಧನ ವೆಚ್ಚ ಮಾಡುತ್ತವೆ, ಏಕೆಂದರೆ ಅವು ಹೆಚ್ಚು ಕಂಪ್ಯುಟೇಶನಲ್ ಆಗಿ ದುಬಾರಿಯಾಗಿವೆ, ಅಥವಾ ಸ್ಥಿತಿಯ ಭಾಗವಾಗಿ ಸಂಗ್ರಹಿಸಬೇಕಾದ ಡೇಟಾದ ಪ್ರಮಾಣವನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ. ವ್ಯವಹಾರ ಡೇಟಾದಲ್ಲಿನ ಪ್ರತಿ ಬೈಟ್ಗೆ 5 ಇಂಧನದ ಶುಲ್ಕವೂ ಇದೆ. ಶುಲ್ಕ ವ್ಯವಸ್ಥೆಯ ಉದ್ದೇಶವು ಆಕ್ರಮಣಕಾರನು ಅವರು ಬಳಸುವ ಪ್ರತಿ ಸಂಪನ್ಮೂಲಕ್ಕೂ ಅನುಪಾತದಲ್ಲಿ ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ, ಇದರಲ್ಲಿ ಕಂಪ್ಯುಟೇಶನ್, ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಮತ್ತು ಸಂಗ್ರಹಣೆ ಸೇರಿವೆ; ಆದ್ದರಿಂದ, ನೆಟ್ವರ್ಕ್ ಈ ಸಂಪನ್ಮೂಲಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದಲ್ಲಿ ಬಳಸುವಂತೆ ಮಾಡುವ ಯಾವುದೇ ವ್ಯವಹಾರವು ಹೆಚ್ಚಳಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಇಂಧನ ಶುಲ್ಕವನ್ನು ಹೊಂದಿರಬೇಕು.
ಸಂದೇಶಗಳು
ಒಪ್ಪಂದಗಳು ಇತರ ಒಪ್ಪಂದಗಳಿಗೆ "ಸಂದೇಶಗಳನ್ನು" ಕಳುಹಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿವೆ. ಸಂದೇಶಗಳು ವರ್ಚುವಲ್ ವಸ್ತುಗಳಾಗಿದ್ದು ಅವುಗಳನ್ನು ಎಂದಿಗೂ ಕ್ರಮಬದ್ಧಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಎಥೆರಿಯಮ್ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಪರಿಸರದಲ್ಲಿ ಮಾತ್ರ ಅಸ್ತಿತ್ವದಲ್ಲಿರುತ್ತವೆ. ಸಂದೇಶವು ಇವುಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ:
- ಸಂದೇಶದ ಕಳುಹಿಸುವವರು (ಅಂತರ್ನಿಹಿತ)
- ಸಂದೇಶ ಸ್ವೀಕರಿಸುವವರು
- ಸಂದೇಶದೊಂದಿಗೆ ವರ್ಗಾಯಿಸಬೇಕಾದ ಎಥೆರ್ ಮೊತ್ತ
- ಐಚ್ಛಿಕ ಡೇಟಾ ಕ್ಷೇತ್ರ
STARTGAS
ಮೌಲ್ಯ
ಮುಖ್ಯವಾಗಿ, ಸಂದೇಶವು ವ್ಯವಹಾರದಂತೆಯೇ ಇರುತ್ತದೆ, ಆದರೆ ಇದು ಬಾಹ್ಯ ನಟನಿಂದ ಅಲ್ಲ, ಒಂದು ಒಪ್ಪಂದದಿಂದ ಉತ್ಪಾದಿಸಲ್ಪಡುತ್ತದೆ. ಪ್ರಸ್ತುತ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಿರುವ ಒಪ್ಪಂದವು CALL
ಆಪ್ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದಾಗ ಸಂದೇಶವನ್ನು ಉತ್ಪಾದಿಸಲಾಗುತ್ತದೆ, ಇದು ಸಂದೇಶವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ವ್ಯವಹಾರದಂತೆಯೇ, ಸಂದೇಶವು ಸ್ವೀಕರಿಸುವ ಖಾತೆಯು ತನ್ನ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ಹೀಗಾಗಿ, ಒಪ್ಪಂದಗಳು ಬಾಹ್ಯ ನಟರು ಹೊಂದಿರುವಂತೆಯೇ ಇತರ ಒಪ್ಪಂದಗಳೊಂದಿಗೆ ಸಂಬಂಧಗಳನ್ನು ಹೊಂದಿರಬಹುದು.
ವ್ಯವಹಾರ ಅಥವಾ ಒಪ್ಪಂದದಿಂದ ನಿಯೋಜಿಸಲಾದ ಇಂಧನ ಭತ್ಯೆಯು ಆ ವ್ಯವಹಾರ ಮತ್ತು ಎಲ್ಲಾ ಉಪ-ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಗಳಿಂದ ಬಳಸಲ್ಪಟ್ಟ ಒಟ್ಟು ಇಂಧನಕ್ಕೆ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಉದಾಹರಣೆಗೆ, ಬಾಹ್ಯ ನಟ A ಯು B ಗೆ 1000 ಇಂಧನದೊಂದಿಗೆ ವ್ಯವಹಾರವನ್ನು ಕಳುಹಿಸಿದರೆ, ಮತ್ತು B ಯು C ಗೆ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು 600 ಇಂಧನ ಬಳಸಿದರೆ, ಮತ್ತು C ಯ ಆಂತರಿಕ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ಹಿಂತಿರುಗುವ ಮೊದಲು 300 ಇಂಧನ ಬಳಸಿದರೆ, ನಂತರ B ಯು ಇಂಧನ ಮುಗಿದುಹೋಗುವ ಮೊದಲು ಇನ್ನೂ 100 ಇಂಧನ ಖರ್ಚು ಮಾಡಬಹುದು.
ಎಥೆರಿಯಮ್ ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯ
ಎಥೆರಿಯಮ್ ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯ, APPLY(S,TX) -> S'
ಅನ್ನು ಈ ಕೆಳಗಿನಂತೆ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು:
- ವ್ಯವಹಾರವು ಸರಿಯಾಗಿ ರೂಪಗೊಂಡಿದೆಯೇ (ಅಂದರೆ ಸರಿಯಾದ ಸಂಖ್ಯೆಯ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿದೆಯೇ), ಸಹಿ ಮಾನ್ಯವಾಗಿದೆಯೇ, ಮತ್ತು ನಾನ್ಸ್ ಕಳುಹಿಸುವವರ ಖಾತೆಯಲ್ಲಿನ ನಾನ್ಸ್ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಇಲ್ಲದಿದ್ದರೆ, ದೋಷವನ್ನು ತೋರಿಸುತ್ತದೆ.
- ವ್ಯವಹಾರ ಶುಲ್ಕವನ್ನು
STARTGAS * GASPRICE
ಎಂದು ಲೆಕ್ಕಹಾಕಿ, ಮತ್ತು ಸಹಿಯಿಂದ ಕಳುಹಿಸುವ ವಿಳಾಸವನ್ನು ನಿರ್ಧರಿಸಿ. ಕಳುಹಿಸುವವರ ಖಾತೆ ಶಿಲ್ಕುದಿಂದ ಶುಲ್ಕವನ್ನು ಕಡಿತಗೊಳಿಸಿ ಮತ್ತು ಕಳುಹಿಸುವವರ ನಾನ್ಸ್ ಅನ್ನು ಹೆಚ್ಚಿಸಿ. ಖರ್ಚು ಮಾಡಲು ಸಾಕಷ್ಟು ಶಿಲ್ಕು ಇಲ್ಲದಿದ್ದರೆ, ದೋಷವನ್ನು ತೋರಿಸುತ್ತದೆ. GAS = STARTGAS
ಎಂದು ಆರಂಭಿಸಿ, ಮತ್ತು ವ್ಯವಹಾರದಲ್ಲಿನ ಬೈಟ್ಗಳಿಗೆ ಪಾವತಿಸಲು ಪ್ರತಿ ಬೈಟ್ಗೆ ನಿರ್ದಿಷ್ಟ ಪ್ರಮಾಣದ ಗ್ಯಾಸ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ.- ವ್ಯವಹಾರ ಮೌಲ್ಯವನ್ನು ಕಳುಹಿಸುವವರ ಖಾತೆಯಿಂದ ಸ್ವೀಕರಿಸುವ ಖಾತೆಗೆ ವರ್ಗಾಯಿಸಿ. ಸ್ವೀಕರಿಸುವ ಖಾತೆಯು ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿದ್ದರೆ, ಅದನ್ನು ರಚಿಸಿ. ಸ್ವೀಕರಿಸುವ ಖಾತೆಯು ಒಪ್ಪಂದವಾಗಿದ್ದರೆ, ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ಇಂಧನ ಮುಗಿದುಹೋಗುವವರೆಗೆ ಅಥವಾ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಒಪ್ಪಂದದ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ.
- ಕಳುಹಿಸುವವರು ಸಾಕಷ್ಟು ಹಣವನ್ನು ಹೊಂದಿರದ ಕಾರಣ ಮೌಲ್ಯ ವರ್ಗಾವಣೆ ವಿಫಲವಾದರೆ, ಅಥವಾ ಕೋಡ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ಇಂಧನ ಮುಗಿದುಹೋದರೆ, ಶುಲ್ಕಗಳ ಪಾವತಿ ಹೊರತುಪಡಿಸಿ ಎಲ್ಲಾ ಸ್ಥಿತಿ ಬದಲಾವಣೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸಿ, ಮತ್ತು ಶುಲ್ಕಗಳನ್ನು ಮೈನರ್ನ ಖಾತೆಗೆ ಸೇರಿಸಿ.
- ಇಲ್ಲದಿದ್ದರೆ, ಉಳಿದ ಎಲ್ಲಾ ಇಂಧನಕ್ಕಾಗಿ ಶುಲ್ಕಗಳನ್ನು ಕಳುಹಿಸುವವರಿಗೆ ಮರುಪಾವತಿಸಿ, ಮತ್ತು ಬಳಸಿದ ಇಂಧನಕ್ಕೆ ಪಾವತಿಸಿದ ಶುಲ್ಕಗಳನ್ನು ಮೈನರ್ಗೆ ಕಳುಹಿಸಿ.
ಉದಾಹರಣೆಗೆ, ಒಪ್ಪಂದದ ಕೋಡ್ ಹೀಗಿದೆ ಎಂದು ಭಾವಿಸೋಣ:
if !self.storage[calldataload(0)]:
self.storage[calldataload(0)] = calldataload(32)
ಗಮನಿಸಿ, ವಾಸ್ತವದಲ್ಲಿ ಒಪ್ಪಂದದ ಕೋಡ್ ಕಡಿಮೆ-ಮಟ್ಟದ EVM ಕೋಡ್ನಲ್ಲಿ ಬರೆಯಲ್ಪಟ್ಟಿದೆ; ಈ ಉದಾಹರಣೆಯನ್ನು ಸ್ಪಷ್ಟತೆಗಾಗಿ ನಮ್ಮ ಉನ್ನತ-ಮಟ್ಟದ ಭಾಷೆಗಳಲ್ಲಿ ಒಂದಾದ ಸರ್ಪೆಂಟ್ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಮತ್ತು ಇದನ್ನು EVM ಕೋಡ್ಗೆ ಸಂಕಲನ ಮಾಡಬಹುದು. ಒಪ್ಪಂದದ ಸಂಗ್ರಹಣೆಯು ಖಾಲಿಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂದು ಭಾವಿಸೋಣ, ಮತ್ತು 10 ಎಥೆರ್ ಮೌಲ್ಯ, 2000 ಗ್ಯಾಸ್, 0.001 ಎಥೆರ್ ಗ್ಯಾಸ್ಪ್ರೈಸ್, ಮತ್ತು 64 ಬೈಟ್ಗಳ ಡೇಟಾದೊಂದಿಗೆ ವ್ಯವಹಾರವನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ, 0-31 ಬೈಟ್ಗಳು ಸಂಖ್ಯೆ 2
ಅನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ ಮತ್ತು 32-63 ಬೈಟ್ಗಳು ಸ್ಟ್ರಿಂಗ್ CHARLIE
ಅನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯದ ಪ್ರಕ್ರಿಯೆಯು ಈ ಕೆಳಗಿನಂತಿದೆ:
- ವ್ಯವಹಾರವು ಮಾನ್ಯ ಮತ್ತು ಸರಿಯಾಗಿ ರೂಪುಗೊಂಡಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
- ವ್ಯವಹಾರ ಕಳುಹಿಸುವವರು ಕನಿಷ್ಠ 2000 * 0.001 = 2 ಎಥೆರ್ ಹೊಂದಿದ್ದಾರೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಹಾಗಿದ್ದರೆ, ಕಳುಹಿಸುವವರ ಖಾತೆಯಿಂದ 2 ಎಥೆರ್ ಕಡಿತಗೊಳಿಸಿ.
- ಇಂಧನ= 2000 ಎಂದು ಆರಂಭಿಸಿ; ವ್ಯವಹಾರವು 170 ಬೈಟ್ಗಳ ಉದ್ದವಿದೆ ಎಂದು ಭಾವಿಸಿ ಮತ್ತು ಬೈಟ್-ಶುಲ್ಕವು 5 ಆಗಿದೆ, 850 ಅನ್ನು ಕಡಿತಗೊಳಿಸಿ ಆದ್ದರಿಂದ 1150 ಇಂಧನ ಉಳಿದಿದೆ.
- ಕಳುಹಿಸುವವರ ಖಾತೆಯಿಂದ 10 ಎಥೆರ್ ಹೆಚ್ಚು ಕಡಿತಗೊಳಿಸಿ, ಮತ್ತು ಅದನ್ನು ಒಪ್ಪಂದದ ಖಾತೆಗೆ ಸೇರಿಸಿ.
- ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಸರಳವಾಗಿದೆ: ಇದು ಒಪ್ಪಂದದ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಸೂಚ್ಯಂಕ
2
ನಲ್ಲಿ ಬಳಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಅದು ಬಳಸಲಾಗಿಲ್ಲ ಎಂದು ಗಮನಿಸುತ್ತದೆ, ಮತ್ತು ಹೀಗಾಗಿ ಅದು ಸೂಚ್ಯಂಕ2
ನಲ್ಲಿನ ಸಂಗ್ರಹಣೆಯನ್ನುCHARLIE
ಮೌಲ್ಯಕ್ಕೆ ಹೊಂದಿಸುತ್ತದೆ. ಇದಕ್ಕೆ 187 ಇಂಧನ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಭಾವಿಸೋಣ, ಆದ್ದರಿಂದ ಉಳಿದ ಇಂಧನ ಪ್ರಮಾಣವು 1150 - 187 = 963 - 963 * 0.001 = 0.963 ಎಥೆರ್ ಅನ್ನು ಕಳುಹಿಸುವವರ ಖಾತೆಗೆ ಹಿಂತಿರುಗಿಸಿ, ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ಸ್ಥಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸಿ.
ವ್ಯವಹಾರದ ಸ್ವೀಕರಿಸುವ ತುದಿಯಲ್ಲಿ ಯಾವುದೇ ಒಪ್ಪಂದವಿಲ್ಲದಿದ್ದರೆ, ಆಗ ಒಟ್ಟು ವ್ಯವಹಾರ ಶುಲ್ಕವು ಕೇವಲ ಒದಗಿಸಿದ GASPRICE
ಅನ್ನು ಬೈಟ್ಗಳಲ್ಲಿ ವ್ಯವಹಾರದ ಉದ್ದದೊಂದಿಗೆ ಗುಣಿಸಿದ್ದಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ, ಮತ್ತು ವ್ಯವಹಾರದೊಂದಿಗೆ ಕಳುಹಿಸಿದ ಡೇಟಾವು ಅಪ್ರಸ್ತುತವಾಗಿರುತ್ತದೆ.
ಹಿಂತಿರುಗುವಿಕೆಗಳ ವಿಷಯದಲ್ಲಿ ಸಂದೇಶಗಳು ವ್ಯವಹಾರಗಳಿಗೆ ಸಮಾನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ: ಸಂದೇಶ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ಇಂಧನ ಮುಗಿದುಹೋದರೆ, ಆ ಸಂದೇಶದ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಮತ್ತು ಆ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯಿಂದ ಟ್ರಿಗರ್ ಆದ ಎಲ್ಲಾ ಇತರ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಗಳು ಹಿಂತಿರುಗುತ್ತವೆ, ಆದರೆ ಮೂಲ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಗಳು ಹಿಂತಿರುಗುವ ಅಗತ್ಯವಿಲ್ಲ. ಇದರರ್ಥ A ಯು B ಯನ್ನು G ಇಂಧನದೊಂದಿಗೆ ಕರೆದರೆ A ಯ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ಗರಿಷ್ಠ G ಇಂಧನವನ್ನು ಮಾತ್ರ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಖಾತರಿಪಡಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಒಂದು ಒಪ್ಪಂದವು ಇನ್ನೊಂದು ಒಪ್ಪಂದವನ್ನು ಕರೆಯುವುದು "ಸುರಕ್ಷಿತ" ಎಂದರ್ಥ. ಅಂತಿಮವಾಗಿ, ಒಂದು ಒಪ್ಕೋಡ್ ಇದೆ, CREATE
, ಇದು ಒಂದು ಒಪ್ಪಂದವನ್ನು ರಚಿಸುತ್ತದೆ; ಇದರ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಯಾಂತ್ರಿಕತೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ CALL
ನಂತೆಯೇ ಇರುತ್ತವೆ, ಆದರೆ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಫಲಿತಾಂಶವು ಹೊಸದಾಗಿ ರಚಿಸಲಾದ ಒಪ್ಪಂದದ ಕೋಡ್ ಅನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ ಎಂಬುದು ವ್ಯತ್ಯಾಸ.
ಕೋಡ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ
ಎಥೆರಿಯಮ್ ಒಪ್ಪಂದಗಳಲ್ಲಿನ ಕೋಡ್ ಅನ್ನು ಕಡಿಮೆ-ಮಟ್ಟದ, ಸ್ಟ್ಯಾಕ್-ಆಧಾರಿತ ಬೈಟ್ಕೋಡ್ ಭಾಷೆಯಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಇದನ್ನು "ಎಥೆರಿಯಮ್ ವರ್ಚುವಲ್ ಮಷೀನ್ ಕೋಡ್" ಅಥವಾ "EVM ಕೋಡ್" ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ. ಕೋಡ್ ಅನೇಕ ಬೈಟ್ಗಳ ಸರಣಿಯನ್ನು ಒಳಗೊಂಡಿದೆ, ಪ್ರತಿ ಬೈಟ್ ಒಂದು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಕೋಡ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ಒಂದು ಅನಂತ ಲೂಪ್ ಆಗಿದೆ, ಇದು ಪ್ರಸ್ತುತ ಪ್ರೋಗ್ರಾಂ ಕೌಂಟರ್ನಲ್ಲಿರುವ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪದೇ ಪದೇ ನಿರ್ವಹಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ (ಇದು ಶೂನ್ಯದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ) ಮತ್ತು ನಂತರ ಕೋಡ್ನ ಅಂತ್ಯವನ್ನು ತಲುಪುವವರೆಗೆ ಅಥವಾ ದೋಷ ಅಥವಾ STOP
ಅಥವಾ RETURN
ಸೂಚನೆಯನ್ನು ಪತ್ತೆ ಮಾಡುವವರೆಗೆ ಪ್ರೋಗ್ರಾಂ ಕೌಂಟರ್ ಅನ್ನು ಒಂದರಿಂದ ಹೆಚ್ಚಿಸುತ್ತದೆ. ಕಾರ್ಯಾಚರಣೆಗಳು ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಮೂರು ರೀತಿಯ ಸ್ಥಳಗಳನ್ನು ಪ್ರವೇಶಿಸಬಹುದು:
- ಒಂದು ಸ್ಟ್ಯಾಕ್, ಒಂದು ಲಾಸ್ಟ್-ಇನ್-ಫಸ್ಟ್-ಔಟ್ ಕಂಟೈನರ್ ಇದರಲ್ಲಿ ಮೌಲ್ಯಗಳನ್ನು ಒತ್ತಬಹುದು ಮತ್ತು ಪಾಪ್ ಮಾಡಬಹುದು
- ಮೆಮೊರಿ, ಅನಂತವಾಗಿ ವಿಸ್ತರಿಸಬಹುದಾದ ಬೈಟ್ ಸರಣಿ
- ಒಪ್ಪಂದದ ದೀರ್ಘಾವಧಿಯ ಸಂಗ್ರಹಣೆ, ಒಂದು ಕೀ/ಮೌಲ್ಯ ಸಂಗ್ರಹ. ಸ್ಟ್ಯಾಕ್ ಮತ್ತು ಮೆಮೊರಿಯಂತೆ ಅಲ್ಲದೆ, ಇವು ಗಣನೆ ಮುಗಿದ ನಂತರ ಮರುಹೊಂದಿಸುತ್ತವೆ, ಸಂಗ್ರಹಣೆಯು ದೀರ್ಘಾವಧಿಗೆ ಉಳಿಯುತ್ತದೆ.
ಕೋಡ್ ಬರುವ ಸಂದೇಶದ ಮೌಲ್ಯ, ಕಳುಹಿಸುವವರು ಮತ್ತು ಡೇಟಾವನ್ನು ಸಹ ಪ್ರವೇಶಿಸಬಹುದು, ಜೊತೆಗೆ ಬ್ಲಾಕ್ ಹೆಡರ್ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಬಹುದು, ಮತ್ತು ಕೋಡ್ ಔಟ್ಪುಟ್ ಆಗಿ ಡೇಟಾದ ಬೈಟ್ ಸರಣಿಯನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು.
EVM ಕೋಡ್ನ ಔಪಚಾರಿಕ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಮಾದರಿಯು ಆಶ್ಚರ್ಯಕರವಾಗಿ ಸರಳವಾಗಿದೆ. ಎಥೆರಿಯಮ್ ವರ್ಚುವಲ್ ಮಷೀನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವಾಗ, ಅದರ ಸಂಪೂರ್ಣ ಗಣನಾ ಸ್ಥಿತಿಯನ್ನು (block_state, transaction, message, code, memory, stack, pc, gas)
ಎಂಬ ಟ್ಯೂಪಲ್ನಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು, ಇಲ್ಲಿ block_state
ಎಲ್ಲಾ ಖಾತೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಜಾಗತಿಕ ಸ್ಥಿತಿಯಾಗಿದೆ ಮತ್ತು ಬ್ಯಾಲೆನ್ಸ್ ಮತ್ತು ಸಂಗ್ರಹಣೆಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಪ್ರತಿ ಸುತ್ತಿನ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಪ್ರಾರಂಭದಲ್ಲಿ, ಪ್ರಸ್ತುತ ಸೂಚನೆಯನ್ನು code
pc
th ಬೈಟ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮೂಲಕ ಕಂಡುಹಿಡಿಯಲಾಗುತ್ತದೆ (ಅಥವಾ pc >= len(code
) ಆದರೆ 0), ಮತ್ತು ಪ್ರತಿ ಸೂಚನೆಯು ಅದು ಟ್ಯೂಪಲ್ ಅನ್ನು ಹೇಗೆ ಪ್ರಭಾವಿಸುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ತನ್ನದೇ ಆದ ವ್ಯಾಖ್ಯಾನವನ್ನು ಹೊಂದಿದೆ. ಉದಾಹರಣೆಗೆ, ADD
ಸ್ಟ್ಯಾಕ್ನಿಂದ ಎರಡು ಐಟಂಗಳನ್ನು ಪಾಪ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ಮೊತ್ತವನ್ನು ಒತ್ತುತ್ತದೆ, gas
1 ರಿಂದ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು pc
ಅನ್ನು 1 ರಿಂದ ಹೆಚ್ಚಿಸುತ್ತದೆ, ಮತ್ತು SSTORE
ಸ್ಟ್ಯಾಕ್ನಿಂದ ಮೇಲಿನ ಎರಡು ಐಟಂಗಳನ್ನು ಪಾಪ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಎರಡನೇ ಐಟಂ ಅನ್ನು ಮೊದಲ ಐಟಂನಿಂದ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸೂಚ್ಯಂಕದಲ್ಲಿ ಒಪ್ಪಂದದ ಸಂಗ್ರಹಣೆಗೆ ಸೇರಿಸುತ್ತದೆ. ಎಥೆರಿಯಮ್ ವರ್ಚುವಲ್ ಮಷಿನ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಜಸ್ಟ್-ಇನ್-ಟೈಮ್ ಕಂಪೈಲೇಶನ್ ಮೂಲಕ ಅನುಕೂಲಿಸಲು ಹಲವಾರು ಮಾರ್ಗಗಳಿದ್ದರೂ, ಎಥೆರಿಯಮ್ನ ಮೂಲ ಅನುಷ್ಠಾನವನ್ನು ಕೆಲವು ನೂರು ಸಾಲುಗಳ ಕೋಡ್ನಲ್ಲಿ ಮಾಡಬಹುದು.
ಬ್ಲಾಕ್ಚೈನ್ ಮತ್ತು ಮೈನಿಂಗ್
ಎಥೆರಿಯಮ್ ಬ್ಲಾಕ್ಚೈನ್ ಹಲವಾರು ರೀತಿಯಲ್ಲಿ ಬಿಟ್ಕಾಯಿನ್ ಬ್ಲಾಕ್ಚೈನ್ಗೆ ಹೋಲುತ್ತದೆ, ಆದರೂ ಇದು ಕೆಲವು ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೊಂದಿದೆ. ಬ್ಲಾಕ್ಚೈನ್ ಸಂರಚನೆಯ ಸಂಬಂಧದಲ್ಲಿ ಎಥೆರಿಯಮ್ ಮತ್ತು ಬಿಟ್ಕಾಯಿನ್ ನಡುವಿನ ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸವೆಂದರೆ, ಬಿಟ್ಕಾಯಿನ್ನಂತೆ ಅಲ್ಲದೆ, ಎಥೆರಿಯಮ್ ಬ್ಲಾಕ್ಗಳು ವ್ಯವಹಾರ ಪಟ್ಟಿ ಮತ್ತು ಇತ್ತೀಚಿನ ಸ್ಥಿತಿ ಎರಡರ ಪ್ರತಿಯನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಅದರ ಹೊರತಾಗಿ, ಎರಡು ಇತರ ಮೌಲ್ಯಗಳಾದ ಬ್ಲಾಕ್ ಸಂಖ್ಯೆ ಮತ್ತು ಕಷ್ಟದ ಮಟ್ಟವನ್ನು ಸಹ ಬ್ಲಾಕ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಎಥೆರಿಯಮ್ನಲ್ಲಿನ ಮೂಲ ಬ್ಲಾಕ್ ಮೌಲ್ಯಮಾಪನ ಕ್ರಮವಿಧಿಯು ಈ ಕೆಳಗಿನಂತಿದೆ:
- ಉಲ್ಲೇಖಿಸಲಾದ ಹಿಂದಿನ ಬ್ಲಾಕ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಮಾನ್ಯವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
- ಬ್ಲಾಕ್ನ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಉಲ್ಲೇಖಿಸಲಾದ ಹಿಂದಿನ ಬ್ಲಾಕ್ಗಿಂತ ಹೆಚ್ಚಾಗಿದೆ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ 15 ನಿಮಿಷಗಳಿಗಿಂತ ಕಡಿಮೆ ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ
- ಬ್ಲಾಕ್ ಸಂಖ್ಯೆ, ಕಷ್ಟದ ಮಟ್ಟ, ವ್ಯವಹಾರ ಮೂಲ, ಅಂಕಲ್ ಮೂಲ ಮತ್ತು ಇಂಧನ ಮಿತಿ (ವಿವಿಧ ಕಡಿಮೆ-ಮಟ್ಟದ ಎಥೆರಿಯಮ್-ನಿರ್ದಿಷ್ಟ ಪರಿಕಲ್ಪನೆಗಳು) ಮಾನ್ಯವಾಗಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
- ಬ್ಲಾಕ್ನಲ್ಲಿನ ಪ್ರೂಫ್-ಆಫ್-ವರ್ಕ್ ಮಾನ್ಯವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
S[0]
ಹಿಂದಿನ ಬ್ಲಾಕ್ನ ಕೊನೆಯಲ್ಲಿನ ಸ್ಥಿತಿ ಎಂದು ಭಾವಿಸಿ.TX
ಬ್ಲಾಕ್ನ ವ್ಯವಹಾರ ಪಟ್ಟಿಯಾಗಿರಲಿ,n
ವ್ಯವಹಾರಗಳೊಂದಿಗೆ. ಒಂದು0...n-1
ನಲ್ಲಿನ ಎಲ್ಲಾi
ಗಾಗಿ,S[i+1] = APPLY(S[i],TX[i])
ಎಂದು ಹೊಂದಿಸಿ. ಯಾವುದೇ ಅನ್ವಯಗಳು ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ, ಅಥವಾ ಈ ಹಂತದವರೆಗೆ ಬ್ಲಾಕ್ನಲ್ಲಿ ಬಳಸಲಾದ ಒಟ್ಟು ಅನಿಲವುGASLIMIT
ಅನ್ನು ಮೀರಿದರೆ, ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸಿ.S_FINAL
S[n]
ಆಗಿರಲಿ, ಆದರೆ ಮೈನರ್ಗೆ ಪಾವತಿಸಿದ ಬ್ಲಾಕ್ ಬಹುಮಾನವನ್ನು ಸೇರಿಸಿ.- ಸ್ಥಿತಿ
S_FINAL
ನ ಮರ್ಕಲ್ ಟ್ರೀ ಮೂಲವು ಬ್ಲಾಕ್ ಹೆಡರ್ನಲ್ಲಿ ಒದಗಿಸಲಾದ ಅಂತಿಮ ಸ್ಥಿತಿ ಮೂಲಕ್ಕೆ ಸಮನಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಹಾಗಿದ್ದರೆ, ಬ್ಲಾಕ್ ಮಾನ್ಯವಾಗಿದೆ; ಇಲ್ಲದಿದ್ದರೆ, ಅದು ಮಾನ್ಯವಾಗಿಲ್ಲ.
ಈ ವಿಧಾನವು ಮೊದಲ ನೋಟಕ್ಕೆ ಅತ್ಯಂತ ಅಸಮರ್ಪಕವಾಗಿ ಕಾಣಿಸಬಹುದು, ಏಕೆಂದರೆ ಇದು ಪ್ರತಿ ಬ್ಲಾಕ್ನೊಂದಿಗೆ ಸಂಪೂರ್ಣ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಬೇಕಾಗುತ್ತದೆ, ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ದಕ್ಷತೆಯು ಬಿಟ್ಕಾಯಿನ್ಗೆ ಹೋಲಿಕೆಯಾಗಬೇಕು. ಕಾರಣವೆಂದರೆ ಸ್ಥಿತಿಯನ್ನು ಟ್ರೀ ರಚನೆಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಬ್ಲಾಕ್ ನಂತರ ಮರದ ಒಂದು ಸಣ್ಣ ಭಾಗವನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ. ಹೀಗಾಗಿ, ಸಾಮಾನ್ಯವಾಗಿ, ಎರಡು ಹತ್ತಿರದ ಬ್ಲಾಕ್ಗಳ ನಡುವೆ ಮರದ ಬಹುಪಾಲು ಭಾಗವು ಒಂದೇ ಆಗಿರಬೇಕು, ಮತ್ತು ಆದ್ದರಿಂದ ಡೇಟಾವನ್ನು ಒಮ್ಮೆ ಸಂಗ್ರಹಿಸಬಹುದು ಮತ್ತು ಸೂಚಕಗಳನ್ನು ಬಳಸಿ (ಅಂದರೆ ಉಪಮರಗಳ ಹ್ಯಾಶ್ಗಳು) ಎರಡು ಬಾರಿ ಉಲ್ಲೇಖಿಸಬಹುದು. ಈ ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯವನ್ನು ಸಾಧಿಸಲು "ಪ್ಯಾಟ್ರೀಶಿಯಾ ಮರ" ಎಂದು ಕರೆಯಲಾಗುವ ವಿಶೇಷ ರೀತಿಯ ಮರವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಇದು ಮರ್ಕಲ್ ಮರದ ಪರಿಕಲ್ಪನೆಯಲ್ಲಿ ಮಾರ್ಪಾಡನ್ನು ಒಳಗೊಂಡಿದೆ, ಇದು ನೋಡ್ಗಳನ್ನು ಸೇರಿಸಲು ಮತ್ತು ಅಳಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಕೇವಲ ಬದಲಾಯಿಸುವುದಷ್ಟೇ ಅಲ್ಲ, ದಕ್ಷತೆಯಿಂದ ಆಗಿದೆ. ಇದಲ್ಲದೆ, ಎಲ್ಲಾ ಸ್ಥಿತಿ ಮಾಹಿತಿಯು ಕೊನೆಯ ಬ್ಲಾಕ್ನ ಭಾಗವಾಗಿರುವುದರಿಂದ, ಸಂಪೂರ್ಣ ಬ್ಲಾಕ್ಚೈನ್ ಇತಿಹಾಸವನ್ನು ಸಂಗ್ರಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ - ಈ ತಂತ್ರವನ್ನು ಬಿಟ್ಕಾಯಿನ್ಗೆ ಅನ್ವಯಿಸಬಹುದಾದರೆ, ಅದು ಸ್ಥಳದಲ್ಲಿ 5-20 ಪಟ್ಟು ಉಳಿತಾಯವನ್ನು ಒದಗಿಸುತ್ತದೆ ಎಂದು ಲೆಕ್ಕ ಹಾಕಬಹುದು.
ಸಾಮಾನ್ಯವಾಗಿ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಯೆಂದರೆ ಭೌತಿಕ ಯಂತ್ರಾಂಶದ ದೃಷ್ಟಿಯಿಂದ ಒಪ್ಪಂದದ ಕೋಡ್ ಅನ್ನು "ಎಲ್ಲಿ" ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಇದಕ್ಕೆ ಸರಳ ಉತ್ತರವಿದೆ: ಒಪ್ಪಂದದ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯದ ವ್ಯಾಖ್ಯಾನದ ಭಾಗವಾಗಿದೆ, ಇದು ಬ್ಲಾಕ್ ಮೌಲ್ಯಮಾಪನ ಕ್ರಮವಿಧಿಯ ಭಾಗವಾಗಿದೆ. ಹೀಗಾಗಿ ಒಂದು ವ್ಯವಹಾರವನ್ನು ಬ್ಲಾಕ್ B
ಗೆ ಸೇರಿಸಿದರೆ, ಆ ವ್ಯವಹಾರದಿಂದ ಉಂಟಾಗುವ ಕೋಡ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಎಲ್ಲಾ ನೋಡ್ಗಳು, ಈಗ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ, ಬ್ಲಾಕ್ B
ಅನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡಿ ಮೌಲ್ಯೀಕರಿಸುವ ಎಲ್ಲಾ ನೋಡ್ಗಳಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ.
ಅಪ್ಲಿಕೇಶನ್ಗಳು
ಸಾಮಾನ್ಯವಾಗಿ, ಎಥೆರಿಯಮ್ ಮೇಲೆ ಮೂರು ರೀತಿಯ ಅಪ್ಲಿಕೇಶನ್ಗಳಿವೆ. ಮೊದಲ ವರ್ಗವು ಹಣಕಾಸು ಅಪ್ಲಿಕೇಶನ್ಗಳು, ಇವು ಬಳಕೆದಾರರಿಗೆ ತಮ್ಮ ಹಣವನ್ನು ನಿರ್ವಹಿಸಲು ಮತ್ತು ಒಪ್ಪಂದಗಳನ್ನು ಮಾಡಿಕೊಳ್ಳಲು ಹೆಚ್ಚು ಶಕ್ತಿಯುತ ಮಾರ್ಗಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ. ಇದು ಉಪ-ಕರೆನ್ಸಿಗಳು, ಹಣಕಾಸು ಡೆರಿವೇಟಿವ್ಗಳು, ಹೆಡ್ಜಿಂಗ್ ಒಪ್ಪಂದಗಳು, ಉಳಿತಾಯ ವಾಲೆಟ್ಗಳು, ಉಯಿಲುಗಳು ಮತ್ತು ಕೊನೆಗೆ ಕೆಲವು ವರ್ಗಗಳ ಪೂರ್ಣ-ಪ್ರಮಾಣದ ಉದ್ಯೋಗ ಒಪ್ಪಂದಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಎರಡನೇ ವರ್ಗವು ಅರೆ-ಹಣಕಾಸು ಅಪ್ಲಿಕೇಶನ್ಗಳು, ಇಲ್ಲಿ ಹಣವು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಆದರೆ ಮಾಡಲಾಗುತ್ತಿರುವುದರಲ್ಲಿ ಹಣವೇತರ ಅಂಶವೂ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ; ಗಣನಾ ಸಮಸ್ಯೆಗಳಿಗೆ ಪರಿಹಾರಗಳಿಗಾಗಿ ಸ್ವಯಂ-ಜಾರಿಗೊಳಿಸುವ ಬಹುಮಾನಗಳು ಇದಕ್ಕೆ ಉತ್ತಮ ಉದಾಹರಣೆಯಾಗಿದೆ. ಕೊನೆಯದಾಗಿ, ಆನ್ಲೈನ್ ಮತದಾನ ಮತ್ತು ವಿಕೇಂದ್ರೀಕೃತ ಆಡಳಿತದಂತಹ ಅಪ್ಲಿಕೇಶನ್ಗಳಿವೆ, ಇವು ಹಣಕಾಸಿಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ.
ಟೋಕನ್ ವ್ಯವಸ್ಥೆಗಳು
ಬ್ಲಾಕ್ಚೈನ್-ಮೇಲಿನ ಟೋಕನ್ ವ್ಯವಸ್ಥೆಗಳು USD ಅಥವಾ ಚಿನ್ನದಂತಹ ಆಸ್ತಿಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಉಪ-ಕರೆನ್ಸಿಗಳಿಂದ ಹಿಡಿದು ಕಂಪನಿ ಷೇರುಗಳು, ಸ್ಮಾರ್ಟ್ ಆಸ್ತಿಯನ್ನು ಪ್ರತಿನಿಧಿಸುವ ವೈಯಕ್ತಿಕ ಟೋಕನ್ಗಳು, ಸುರಕ್ಷಿತ ನಕಲಿಸಲಾಗದ ಕೂಪನ್ಗಳು, ಮತ್ತು ಸಾಂಪ್ರದಾಯಿಕ ಮೌಲ್ಯದೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲದ ಟೋಕನ್ ವ್ಯವಸ್ಥೆಗಳು, ಪ್ರೋತ್ಸಾಹಕ್ಕಾಗಿ ಪಾಯಿಂಟ್ ವ್ಯವಸ್ಥೆಗಳಾಗಿ ಬಳಸುವವರೆಗೆ ಹಲವಾರು ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಹೊಂದಿವೆ. ಟೋಕನ್ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಎಥೆರಿಯಮ್ನಲ್ಲಿ ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು ಆಶ್ಚರ್ಯಕರವಾಗಿ ಸುಲಭವಾಗಿದೆ. ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾದ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ, ಒಂದು ಕರೆನ್ಸಿ ಅಥವಾ ಟೋಕನ್ ವ್ಯವಸ್ಥೆಯು ಮೂಲಭೂತವಾಗಿ ಒಂದು ಡೇಟಾಬೇಸ್ ಆಗಿದ್ದು, ಅದರಲ್ಲಿ ಒಂದೇ ಕಾರ್ಯಾಚರಣೆ ಇರುತ್ತದೆ: A ಯಿಂದ X ಯೂನಿಟ್ಗಳನ್ನು ಕಳೆದು B ಗೆ X ಯೂನಿಟ್ಗಳನ್ನು ನೀಡುವುದು. ಇದಕ್ಕೆ ಎರಡು ಷರತ್ತುಗಳಿವೆ: (i) ವ್ಯವಹಾರಕ್ಕೆ ಮುಂಚೆ A ಯ ಬಳಿ ಕನಿಷ್ಠ X ಯೂನಿಟ್ಗಳು ಇದ್ದಿರಬೇಕು ಮತ್ತು (2) ವ್ಯವಹಾರವನ್ನು A ಅನುಮೋದಿಸಿರಬೇಕು. ಒಂದು ಟೋಕನ್ ವ್ಯವಸ್ಥೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಬೇಕಾದುದೆಲ್ಲ ಈ ತರ್ಕವನ್ನು ಒಂದು ಒಪ್ಪಂದದಲ್ಲಿ ಅಳವಡಿಸುವುದು ಮಾತ್ರ.
ಸರ್ಪೆಂಟ್ನಲ್ಲಿ ಟೋಕನ್ ವ್ಯವಸ್ಥೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಬೇಕಾದ ಮೂಲ ಕೋಡ್ ಹೀಗಿದೆ:
def send(to, value):
if self.storage[msg.sender] >= value:
self.storage[msg.sender] = self.storage[msg.sender] - value
self.storage[to] = self.storage[to] + value
ಇದು ಮೇಲೆ ಈ ದಾಖಲೆಯಲ್ಲಿ ವಿವರಿಸಿದ "ಬ್ಯಾಂಕಿಂಗ್ ವ್ಯವಸ್ಥೆ" ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯದ ಅಕ್ಷರಶಃ ಅನುಷ್ಠಾನವಾಗಿದೆ. ಮೊದಲ ಹಂತದಲ್ಲಿ ಕರೆನ್ಸಿ ಯೂನಿಟ್ಗಳನ್ನು ವಿತರಿಸಲು ಮತ್ತು ಇತರ ಕೆಲವು ವಿಶಿಷ್ಟ ಸಂದರ್ಭಗಳಿಗಾಗಿ ಕೆಲವು ಹೆಚ್ಚುವರಿ ಕೋಡ್ ಸಾಲುಗಳನ್ನು ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ. ಇದಲ್ಲದೆ, ಇತರ ಒಪ್ಪಂದಗಳು ಒಂದು ವಿಳಾಸದ ಬ್ಯಾಲೆನ್ಸ್ ಅನ್ನು ಪ್ರಶ್ನಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುವ ಒಂದು ಕಾರ್ಯವನ್ನು ಸೇರಿಸುವುದು ಉತ್ತಮ. ಸೈದ್ಧಾಂತಿಕವಾಗಿ, ಎಥೆರಿಯಮ್ ಆಧಾರಿತ ಟೋಕನ್ ವ್ಯವಸ್ಥೆಗಳು ಉಪ-ಕರೆನ್ಸಿಗಳಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವಾಗ, ಚೈನ್-ಮೇಲಿನ ಬಿಟ್ಕಾಯಿನ್ ಆಧಾರಿತ ಮೆಟಾ-ಕರೆನ್ಸಿಗಳಿಗೆ ಇಲ್ಲದ ಮತ್ತೊಂದು ಮಹತ್ವದ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಬಹುದು: ವ್ಯವಹಾರ ಶುಲ್ಕಗಳನ್ನು ನೇರವಾಗಿ ಆ ಕರೆನ್ಸಿಯಲ್ಲಿಯೇ ಪಾವತಿಸುವ ಸಾಮರ್ಥ್ಯ. ಸೈದ್ಧಾಂತಿಕವಾಗಿ, ಎಥೆರಿಯಮ್ ಆಧಾರಿತ ಟೋಕನ್ ವ್ಯವಸ್ಥೆಗಳು ಉಪ-ಕರೆನ್ಸಿಗಳಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವಾಗ, ಚೈನ್-ಮೇಲಿನ ಬಿಟ್ಕಾಯಿನ್ ಆಧಾರಿತ ಮೆಟಾ-ಕರೆನ್ಸಿಗಳಿಗೆ ಇಲ್ಲದ ಮತ್ತೊಂದು ಮಹತ್ವದ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಬಹುದು: ವ್ಯವಹಾರ ಶುಲ್ಕಗಳನ್ನು ನೇರವಾಗಿ ಆ ಕರೆನ್ಸಿಯಲ್ಲಿಯೇ ಪಾವತಿಸುವ ಸಾಮರ್ಥ್ಯ. ಇದನ್ನು ಹೀಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು: ಒಪ್ಪಂದವು ಒಂದು ಎಥೆರ್ ಬ್ಯಾಲೆನ್ಸ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ಬ್ಯಾಲೆನ್ಸ್ನಿಂದ ಶುಲ್ಕ ಪಾವತಿಗೆ ಬಳಸಿದ ಎಥೆರ್ ಅನ್ನು ಕಳುಹಿಸುವವರಿಗೆ ಮರುಪಾವತಿಸಲಾಗುತ್ತದೆ. ಈ ಬ್ಯಾಲೆನ್ಸ್ ಅನ್ನು ಮರುಭರ್ತಿ ಮಾಡಲು, ಒಪ್ಪಂದವು ಶುಲ್ಕವಾಗಿ ಸ್ವೀಕರಿಸಿದ ಆಂತರಿಕ ಕರೆನ್ಸಿ ಯೂನಿಟ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ, ನಿರಂತರವಾಗಿ ನಡೆಯುವ ಹರಾಜಿನಲ್ಲಿ ಮರುಮಾರಾಟ ಮಾಡುತ್ತದೆ. ಹೀಗಾಗಿ ಬಳಕೆದಾರರು ತಮ್ಮ ಖಾತೆಗಳನ್ನು ಎಥೆರ್ನೊಂದಿಗೆ "ಸಕ್ರಿಯಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ". ಆದರೆ ಒಮ್ಮೆ ಎಥೆರ್ ಅಲ್ಲಿ ಇರಿಸಿದ ನಂತರ ಅದನ್ನು ಮರುಬಳಕೆ ಮಾಡಬಹುದು, ಏಕೆಂದರೆ ಒಪ್ಪಂದವು ಪ್ರತಿ ಬಾರಿಯೂ ಅದನ್ನು ಮರುಪಾವತಿಸುತ್ತದೆ.
ಹಣಕಾಸು ವ್ಯುತ್ಪನ್ನಗಳು ಮತ್ತು ಸ್ಥಿರ-ಮೌಲ್ಯದ ಕರೆನ್ಸಿಗಳು
ಹಣಕಾಸು ವ್ಯುತ್ಪನ್ನಗಳು "ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದ"ದ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಅನ್ವಯವಾಗಿದ್ದು, ಕೋಡ್ನಲ್ಲಿ ಅನುಷ್ಠಾನಗೊಳಿಸಲು ಸುಲಭವಾದವುಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಹಣಕಾಸು ಒಪ್ಪಂದಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವಲ್ಲಿನ ಮುಖ್ಯ ಸವಾಲೆಂದರೆ, ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಬಾಹ್ಯ ಬೆಲೆ ಟಿಕ್ಕರ್ಗೆ ಉಲ್ಲೇಖವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತವೆ; ಉದಾಹರಣೆಗೆ, ಅಮೆರಿಕನ್ ಡಾಲರ್ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಎಥೆರ್ (ಅಥವಾ ಇನ್ನೊಂದು ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿ) ನ ಅಸ್ಥಿರತೆಯನ್ನು ರಕ್ಷಿಸುವ ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದವು ಬಹಳ ಬಯಸಲ್ಪಡುವ ಅನ್ವಯವಾಗಿದೆ. ಆದರೆ ಇದನ್ನು ಮಾಡಲು ಒಪ್ಪಂದಕ್ಕೆ ETH/USD ನ ಮೌಲ್ಯವೇನೆಂದು ತಿಳಿದಿರಬೇಕು. ಇದನ್ನು ಮಾಡುವ ಅತ್ಯಂತ ಸರಳ ವಿಧಾನವೆಂದರೆ ನಿರ್ದಿಷ್ಟ ಪಕ್ಷದಿಂದ (ಉದಾ. NASDAQ) ನಿರ್ವಹಿಸಲ್ಪಡುವ "ಡೇಟಾ ಫೀಡ್" ಒಪ್ಪಂದದ ಮೂಲಕ. ಈ ಒಪ್ಪಂದವು ಆ ಪಕ್ಷಕ್ಕೆ ಅಗತ್ಯವಿದ್ದಾಗ ನವೀಕರಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀಡುವಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಲ್ಪಟ್ಟಿರುತ್ತದೆ. ಅಲ್ಲದೆ ಇತರ ಒಪ್ಪಂದಗಳು ಈ ಒಪ್ಪಂದಕ್ಕೆ ಸಂದೇಶ ಕಳುಹಿಸಿ ಬೆಲೆಯನ್ನು ಒದಗಿಸುವ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಲು ಅನುವು ಮಾಡಿಕೊಡುವ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಈ ನಿರ್ಣಾಯಕ ಘಟಕವನ್ನು ನೀಡಿದರೆ, ರಕ್ಷಣಾ ಒಪ್ಪಂದವು ಈ ಕೆಳಗಿನಂತೆ ಕಾಣುತ್ತದೆ:
- ಪಕ್ಷ A 1000 ಎಥೆರ್ ಅನ್ನು ಹೂಡಿಕೆ ಮಾಡುವವರೆಗೆ ಕಾಯಿರಿ.
- ಪಕ್ಷ B 1000 ಎಥೆರ್ ಅನ್ನು ಹೂಡಿಕೆ ಮಾಡುವವರೆಗೆ ಕಾಯಿರಿ.
- ಡೇಟಾ ಫೀಡ್ ಒಪ್ಪಂದವನ್ನು ಪ್ರಶ್ನಿಸುವ ಮೂಲಕ ಲೆಕ್ಕ ಹಾಕಿದ 1000 ಎಥೆರ್ನ USD ಮೌಲ್ಯವನ್ನು ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ದಾಖಲಿಸಿ. ಇದನ್ನು $x ಎಂದು ಹೇಳೋಣ.
- 30 ದಿನಗಳ ನಂತರ, A ಅಥವಾ B ಗೆ ಒಪ್ಪಂದವನ್ನು "ಮರುಸಕ್ರಿಯಗೊಳಿಸಲು" ಅನುಮತಿಸಿ. ಇದರಿಂದ $x ಮೌಲ್ಯದ ಎಥೆರ್ ಅನ್ನು (ಹೊಸ ಬೆಲೆಯನ್ನು ಪಡೆಯಲು ಡೇಟಾ ಫೀಡ್ ಒಪ್ಪಂದವನ್ನು ಮತ್ತೆ ಪ್ರಶ್ನಿಸುವ ಮೂಲಕ ಲೆಕ್ಕ ಹಾಕಿದಂತೆ) A ಗೆ ಮತ್ತು ಉಳಿದದ್ದನ್ನು B ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.
ಇಂತಹ ಒಪ್ಪಂದವು ಕ್ರಿಪ್ಟೋ-ವಾಣಿಜ್ಯದಲ್ಲಿ ಗಣನೀಯ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಪ್ಟೋಕರೆನ್ಸಿ ಬಗ್ಗೆ ಉಲ್ಲೇಖಿಸಲಾಗುವ ಮುಖ್ಯ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದೆಂದರೆ ಅದರ ಅಸ್ಥಿರತೆ; ಅನೇಕ ಬಳಕೆದಾರರು ಮತ್ತು ವ್ಯಾಪಾರಿಗಳು ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಆಸ್ತಿಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುವ ಭದ್ರತೆ ಮತ್ತು ಅನುಕೂಲತೆಯನ್ನು ಬಯಸಬಹುದು. ಆದರೆ ಒಂದೇ ದಿನದಲ್ಲಿ ತಮ್ಮ ನಿಧಿಗಳ ಮೌಲ್ಯದ 23% ನಷ್ಟ ಅನುಭವಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಎದುರಿಸಲು ಅವರು ಬಯಸದಿರಬಹುದು. ಇಲ್ಲಿಯವರೆಗೆ, ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಸ್ತಾಪಿಸಲಾಗುವ ಪರಿಹಾರವೆಂದರೆ ನೀಡುಗ-ಬೆಂಬಲಿತ ಆಸ್ತಿಗಳು. ಈ ಕಲ್ಪನೆಯ ಪ್ರಕಾರ, ಒಬ್ಬ ನೀಡುಗನು ಒಂದು ಉಪ-ಕರೆನ್ಸಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತಾನೆ; ಇದರಲ್ಲಿ ಅವನಿಗೆ ಯೂನಿಟ್ಗಳನ್ನು ನೀಡುವ ಮತ್ತು ಹಿಂಪಡೆಯುವ ಹಕ್ಕಿರುತ್ತದೆ, ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಅಂತರ್ನಿಹಿತ ಆಸ್ತಿಯ (ಉದಾ. ಚಿನ್ನ, USD) ಒಂದು ಯೂನಿಟ್ ಅನ್ನು ಒದಗಿಸುವ ಯಾರಿಗಾದರೂ (ಆಫ್ಲೈನ್ನಲ್ಲಿ) ಕರೆನ್ಸಿಯ ಒಂದು ಯೂನಿಟ್ ಅನ್ನು ನೀಡುತ್ತಾನೆ. ನಂತರ ನೀಡುಗನು ಕ್ರಿಪ್ಟೋ-ಆಸ್ತಿಯ ಒಂದು ಯೂನಿಟ್ ಅನ್ನು ಹಿಂದಿರುಗಿಸುವ ಯಾರಿಗಾದರೂ ಅಂತರ್ನಿಹಿತ ಆಸ್ತಿಯ ಒಂದು ಯೂನಿಟ್ ಅನ್ನು ಒದಗಿಸುವುದಾಗಿ ಭರವಸೆ ನೀಡುತ್ತಾನೆ. ಈ ಕಾರ್ಯವಿಧಾನವು, ನೀಡುಗನನ್ನು ನಂಬಬಹುದಾದರೆ, ಯಾವುದೇ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್-ಅಲ್ಲದ ಆಸ್ತಿಯನ್ನು ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಆಸ್ತಿಯಾಗಿ "ಉನ್ನತೀಕರಿಸಲು" ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ, ನೀಡುಗರು ಯಾವಾಗಲೂ ನಂಬಿಕೆಗೆ ಯೋಗ್ಯರಾಗಿರುವುದಿಲ್ಲ, ಮತ್ತು ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಬ್ಯಾಂಕಿಂಗ್ ಮೂಲಸೌಕರ್ಯವು ತುಂಬಾ ದುರ್ಬಲವಾಗಿರುತ್ತದೆ, ಅಥವಾ ಅಂತಹ ಸೇವೆಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿರಲು ತುಂಬಾ ವಿರೋಧಿಯಾಗಿರುತ್ತದೆ. ಆರ್ಥಿಕ ಡೆರಿವೇಟಿವ್ಗಳು ಒಂದು ಪರ್ಯಾಯವನ್ನು ಒದಗಿಸುತ್ತವೆ. ಇಲ್ಲಿ, ಒಂದು ಆಸ್ತಿಯನ್ನು ಬೆಂಬಲಿಸಲು ಒಬ್ಬ ನೀಡುಗನು ನಿಧಿಗಳನ್ನು ಒದಗಿಸುವ ಬದಲು, ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಉಲ್ಲೇಖ ಆಸ್ತಿಯ (ಉದಾ. ETH) ಬೆಲೆ ಏರುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಊಹಾಪೋಹಕರ ವಿಕೇಂದ್ರೀಕೃತ ಮಾರುಕಟ್ಟೆ ಆ ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ. ನೀಡುಗರಿಗೆ ವಿರುದ್ಧವಾಗಿ, ಊಹಾಪೋಹಕರು ತಮ್ಮ ಒಪ್ಪಂದದ ಭಾಗವನ್ನು ಉಲ್ಲಂಘಿಸುವ ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ರಕ್ಷಣಾ ಒಪ್ಪಂದವು ಅವರ ನಿಧಿಗಳನ್ನು ಎಸ್ಕ್ರೋದಲ್ಲಿ ಹಿಡಿದಿರುತ್ತದೆ. ಗಮನಿಸಿ, ಈ ವಿಧಾನವು ಸಂಪೂರ್ಣವಾಗಿ ವಿಕೇಂದ್ರೀಕೃತವಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಬೆಲೆ ಟಿಕ್ಕರ್ ಅನ್ನು ಒದಗಿಸಲು ನಂಬಿಕೆಯ ಮೂಲವು ಇನ್ನೂ ಅಗತ್ಯವಿದೆ, ಆದರೂ ಸಹ, ಇದು ಮೂಲಸೌಕರ್ಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುವ ದೃಷ್ಟಿಯಿಂದ (ನೀಡುಗನಾಗಿರುವುದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಬೆಲೆ ಫೀಡ್ ನೀಡಲು ಯಾವುದೇ ಪರವಾನಗಿಗಳ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಇದನ್ನು ಭಾಷಣ ಸ್ವಾತಂತ್ರ್ಯವಾಗಿ ವರ್ಗೀಕರಿಸಬಹುದು) ಮತ್ತು ವಂಚನೆಯ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವ ದೃಷ್ಟಿಯಿಂದ ಗಣನೀಯ ಸುಧಾರಣೆಯಾಗಿದೆ ಎಂದು ವಾದಿಸಬಹುದು.
ಗುರುತು ಮತ್ತು ಖ್ಯಾತಿ ವ್ಯವಸ್ಥೆಗಳು
ಎಲ್ಲಕ್ಕಿಂತ ಮೊದಲ ಪರ್ಯಾಯ ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿಯಾದ ನೇಮ್ಕಾಯಿನ್(opens in a new tab), ಹೆಸರು ನೋಂದಣಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಒದಗಿಸಲು ಬಿಟ್ಕಾಯಿನ್-ತರಹದ ಬ್ಲಾಕ್ಚೈನ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿತು. ಇಲ್ಲಿ ಬಳಕೆದಾರರು ತಮ್ಮ ಹೆಸರುಗಳನ್ನು ಇತರ ಡೇಟಾದೊಂದಿಗೆ ಸಾರ್ವಜನಿಕ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ನೋಂದಾಯಿಸಬಹುದು. ಪ್ರಮುಖವಾಗಿ ಉಲ್ಲೇಖಿಸಲಾದ ಬಳಕೆಯ ಪ್ರಕರಣವೆಂದರೆ DNS(opens in a new tab) ವ್ಯವಸ್ಥೆ. ಇದು "bitcoin.org" (ಅಥವಾ, ನೇಮ್ಕಾಯಿನ್ನ ಸಂದರ್ಭದಲ್ಲಿ, "bitcoin.bit") ನಂತಹ ಡೊಮೇನ್ ಹೆಸರುಗಳನ್ನು IP ವಿಳಾಸಕ್ಕೆ ಮ್ಯಾಪ್ ಮಾಡುತ್ತದೆ. ಇತರ ಬಳಕೆಯ ಪ್ರಕರಣಗಳಲ್ಲಿ ಇಮೇಲ್ ದೃಢೀಕರಣ ಮತ್ತು ಸಂಭವನೀಯವಾಗಿ ಹೆಚ್ಚು ಸುಧಾರಿತ ಖ್ಯಾತಿ ವ್ಯವಸ್ಥೆಗಳು ಸೇರಿವೆ. ಎಥೆರಿಯಮ್ನಲ್ಲಿ ನೇಮ್ಕಾಯಿನ್-ತರಹದ ಹೆಸರು ನೋಂದಣಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಒದಗಿಸುವ ಮೂಲ ಒಪ್ಪಂದ ಇಲ್ಲಿದೆ:
def register(name, value):
if !self.storage[name]:
self.storage[name] = value
ಒಪ್ಪಂದವು ತುಂಬಾ ಸರಳವಾಗಿದೆ; ಇದು ಎಥೆರಿಯಮ್ ನೆಟ್ವರ್ಕ್ನೊಳಗೆ ಇರುವ ಒಂದು ಡೇಟಾಬೇಸ್ ಆಗಿದ್ದು, ಇದಕ್ಕೆ ಸೇರಿಸಬಹುದು, ಆದರೆ ಮಾರ್ಪಡಿಸಲಾಗುವುದಿಲ್ಲ ಅಥವಾ ತೆಗೆದುಹಾಕಲಾಗುವುದಿಲ್ಲ. ಯಾರಾದರೂ ಒಂದು ಹೆಸರನ್ನು ಕೆಲವು ಮೌಲ್ಯದೊಂದಿಗೆ ನೋಂದಾಯಿಸಬಹುದು, ಮತ್ತು ಆ ನೋಂದಣಿ ನಂತರ ಶಾಶ್ವತವಾಗಿ ಉಳಿಯುತ್ತದೆ. ಹೆಚ್ಚು ಸುಧಾರಿತ ಹೆಸರು ನೋಂದಣಿ ಒಪ್ಪಂದವು ಇತರ ಒಪ್ಪಂದಗಳು ಅದನ್ನು ಪ್ರಶ್ನಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುವ "ಕಾರ್ಯ ಖಂಡ"ವನ್ನು ಸಹ ಹೊಂದಿರುತ್ತದೆ, ಜೊತೆಗೆ ಹೆಸರಿನ "ಮಾಲೀಕ" (ಅಂದರೆ, ಮೊದಲ ನೋಂದಾಯಿಸಿದವರು) ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸಲು ಅಥವಾ ಮಾಲೀಕತ್ವವನ್ನು ವರ್ಗಾಯಿಸಲು ಒಂದು ಕಾರ್ಯವಿಧಾನವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಇದರ ಮೇಲೆ ಖ್ಯಾತಿ ಮತ್ತು ವಿಶ್ವಾಸದ-ಜಾಲ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಹ ಸೇರಿಸಬಹುದು.
ವಿಕೇಂದ್ರೀಕೃತ ಫೈಲ್ ಸಂಗ್ರಹಣೆ
ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಲ್ಲಿ, ಹಲವಾರು ಜನಪ್ರಿಯ ಆನ್ಲೈನ್ ಫೈಲ್ ಸಂಗ್ರಹಣೆ ಸ್ಟಾರ್ಟಪ್ಗಳು ಹೊರಹೊಮ್ಮಿವೆ, ಇವುಗಳಲ್ಲಿ ಅತ್ಯಂತ ಪ್ರಮುಖವಾದುದು ಡ್ರಾಪ್ಬಾಕ್ಸ್. ಇದು ಬಳಕೆದಾರರಿಗೆ ತಮ್ಮ ಹಾರ್ಡ್ ಡ್ರೈವ್ನ ಬ್ಯಾಕಪ್ ಅನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಈ ಸೇವೆಯು ಬ್ಯಾಕಪ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಿ, ಮಾಸಿಕ ಶುಲ್ಕಕ್ಕೆ ಬದಲಾಗಿ ಬಳಕೆದಾರರಿಗೆ ಅದನ್ನು ಪ್ರವೇಶಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಆದರೆ, ಈ ಹಂತದಲ್ಲಿ ಫೈಲ್ ಸಂಗ್ರಹಣೆ ಮಾರುಕಟ್ಟೆಯು ಕೆಲವೊಮ್ಮೆ ಅಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ. ವಿವಿಧ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಹಾರಗಳ ಮೇಲ್ನೋಟವು ತೋರಿಸುವಂತೆ, ವಿಶೇಷವಾಗಿ ದಿ "ಅನ್ಕ್ಯಾನಿ ವ್ಯಾಲಿ" 20-200 GB ಮಟ್ಟದಲ್ಲಿ (ಇಲ್ಲಿ ಉಚಿತ ಕೋಟಾಗಳು ಅಥವಾ ಎಂಟರ್ಪ್ರೈಸ್-ಮಟ್ಟದ ರಿಯಾಯಿತಿಗಳು ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ), ಮುಖ್ಯವಾಹಿನಿಯ ಫೈಲ್ ಸಂಗ್ರಹಣೆಯ ಮಾಸಿಕ ಬೆಲೆಗಳು ಒಂದೇ ತಿಂಗಳಲ್ಲಿ ಸಂಪೂರ್ಣ ಹಾರ್ಡ್ ಡ್ರೈವ್ನ ವೆಚ್ಚಕ್ಕಿಂತ ಹೆಚ್ಚು ಪಾವತಿಸುವಂತಿವೆ. ಎಥೆರಿಯಮ್ ಒಪ್ಪಂದಗಳು ವಿಕೇಂದ್ರೀಕೃತ ಫೈಲ್ ಸಂಗ್ರಹಣೆ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ವಿಕಾಸಕ್ಕೆ ಅನುವು ಮಾಡಿಕೊಡಬಹುದು. ಇಲ್ಲಿ ವೈಯಕ್ತಿಕ ಬಳಕೆದಾರರು ತಮ್ಮ ಸ್ವಂತ ಹಾರ್ಡ್ ಡ್ರೈವ್ಗಳನ್ನು ಬಾಡಿಗೆಗೆ ನೀಡುವ ಮೂಲಕ ಸಣ್ಣ ಪ್ರಮಾಣದ ಹಣವನ್ನು ಗಳಿಸಬಹುದು ಮತ್ತು ಬಳಕೆಯಾಗದ ಸ್ಥಳವನ್ನು ಫೈಲ್ ಸಂಗ್ರಹಣೆಯ ವೆಚ್ಚವನ್ನು ಇನ್ನಷ್ಟು ಕಡಿಮೆ ಮಾಡಲು ಬಳಸಬಹುದು.
ಇಂತಹ ಒಂದು ಸಾಧನದ ಮುಖ್ಯ ಅಡಿಪಾಯ ಭಾಗವೆಂದರೆ ನಾವು "ವಿಕೇಂದ್ರೀಕೃತ ಡ್ರಾಪ್ಬಾಕ್ಸ್ ಒಪ್ಪಂದ" ಎಂದು ಹೆಸರಿಸಿರುವುದು. ಈ ಒಪ್ಪಂದವು ಹೀಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮೊದಲಿಗೆ, ಬಯಸಿದ ಡೇಟಾವನ್ನು ಬ್ಲಾಕ್ಗಳಾಗಿ ವಿಭಜಿಸಿ, ಗೌಪ್ಯತೆಗಾಗಿ ಪ್ರತಿ ಬ್ಲಾಕ್ ಅನ್ನು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿ, ಅದರಿಂದ ಮರ್ಕಲ್ ಮರವನ್ನು ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ. ನಂತರ, ಪ್ರತಿ N ಬ್ಲಾಕ್ಗಳಿಗೊಮ್ಮೆ, ಒಪ್ಪಂದವು ಮರ್ಕಲ್ ಮರದಲ್ಲಿ ಯಾದೃಚ್ಛಿಕ ಸೂಚ್ಯಂಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ (ಹಿಂದಿನ ಬ್ಲಾಕ್ ಹ್ಯಾಶ್ ಅನ್ನು ಯಾದೃಚ್ಛಿಕತೆಯ ಮೂಲವಾಗಿ ಬಳಸಿ, ಇದು ಒಪ್ಪಂದ ಕೋಡ್ನಿಂದ ಲಭ್ಯವಿರುತ್ತದೆ) ನಿಯಮವನ್ನು ಹೊಂದಿರುವ ಒಂದು ಒಪ್ಪಂದವನ್ನು ಮಾಡಲಾಗುತ್ತದೆ. ಮರದಲ್ಲಿ ಆ ನಿರ್ದಿಷ್ಟ ಸೂಚ್ಯಂಕದಲ್ಲಿರುವ ಬ್ಲಾಕ್ನ ಮಾಲೀಕತ್ವದ ಸರಳೀಕೃತ ಪಾವತಿ ಪರಿಶೀಲನೆಯಂತಹ ಪುರಾವೆಯನ್ನು ಒದಗಿಸುವ ವ್ಯವಹಾರವನ್ನು ಮೊದಲು ಸರಬರಾಜು ಮಾಡುವ ಘಟಕಕ್ಕೆ X ಎಥರ್ ಅನ್ನು ನೀಡಲಾಗುತ್ತದೆ. ಬಳಕೆದಾರರು ತಮ್ಮ ಫೈಲ್ ಅನ್ನು ಮರುಡೌನ್ಲೋಡ್ ಮಾಡಲು ಬಯಸಿದಾಗ, ಅವರು ಸೂಕ್ಷ್ಮ ಪಾವತಿ ಚಾನೆಲ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಬಹುದು (ಉದಾ. 32 ಕಿಲೋಬೈಟ್ಗೆ 1 ಸಜಾಬೊ ಪಾವತಿಸಿ) ಫೈಲ್ ಅನ್ನು ಮರುಪಡೆಯಲು; ಅತ್ಯಂತ ಶುಲ್ಕ-ದಕ್ಷ ವಿಧಾನವೆಂದರೆ ಪಾವತಿದಾರನು ವ್ಯವಹಾರವನ್ನು ಕೊನೆಯವರೆಗೂ ಪ್ರಕಟಿಸದಿರುವುದು. ಬದಲಿಗೆ, ಪ್ರತಿ 32 ಕಿಲೋಬೈಟ್ಗಳ ನಂತರ ಅದೇ ನಾನ್ಸ್ನೊಂದಿಗೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಲಾಭದಾಯಕ ವ್ಯವಹಾರದೊಂದಿಗೆ ವ್ಯವಹಾರವನ್ನು ಬದಲಾಯಿಸುವುದು.
ಪ್ರೋಟೋಕಾಲ್ನ ಒಂದು ಮುಖ್ಯ ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ, ಅನೇಕ ಯಾದೃಚ್ಛಿಕ ನೋಡ್ಗಳು ಫೈಲ್ ಅನ್ನು ಮರೆಯಲು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ ಎಂದು ನಂಬುತ್ತಿರುವಂತೆ ಕಂಡರೂ, ಆ ಅಪಾಯವನ್ನು ಸೀಕ್ರೆಟ್ ಶೇರಿಂಗ್ ಮೂಲಕ ಫೈಲ್ ಅನ್ನು ಅನೇಕ ತುಣುಕುಗಳಾಗಿ ವಿಭಜಿಸುವ ಮೂಲಕ ಮತ್ತು ಪ್ರತಿ ತುಣುಕು ಇನ್ನೂ ಯಾವುದಾದರೂ ನೋಡ್ನ ಸ್ವಾಧೀನದಲ್ಲಿದೆಯೇ ಎಂದು ನೋಡಲು ಒಪ್ಪಂದಗಳನ್ನು ಗಮನಿಸುವ ಮೂಲಕ ಸುಮಾರು ಶೂನ್ಯಕ್ಕೆ ಇಳಿಸಬಹುದು. ಒಂದು ಒಪ್ಪಂದವು ಇನ್ನೂ ಹಣವನ್ನು ಪಾವತಿಸುತ್ತಿದ್ದರೆ, ಅದು ಯಾರೋ ಇನ್ನೂ ಫೈಲ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಿಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದಕ್ಕೆ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಪುರಾವೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.
ವಿಕೇಂದ್ರೀಕೃತ ಸ್ವಾಯತ್ತ ಸಂಸ್ಥೆಗಳು
"ವಿಕೇಂದ್ರೀಕೃತ ಸ್ವಾಯತ್ತ ಸಂಸ್ಥೆ"ಯ ಸಾಮಾನ್ಯ ಪರಿಕಲ್ಪನೆಯೆಂದರೆ ಒಂದು ವರ್ಚುವಲ್ ಘಟಕ. ಇದು ನಿರ್ದಿಷ್ಟ ಸದಸ್ಯರು ಅಥವಾ ಷೇರುದಾರರನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಇವರು, ಬಹುಶಃ 67% ಬಹುಮತದೊಂದಿಗೆ, ಘಟಕದ ನಿಧಿಗಳನ್ನು ಖರ್ಚು ಮಾಡುವ ಮತ್ತು ಅದರ ಕೋಡ್ ಅನ್ನು ಮಾರ್ಪಡಿಸುವ ಹಕ್ಕನ್ನು ಹೊಂದಿರುತ್ತಾರೆ. ಸಂಸ್ಥೆಯು ತನ್ನ ನಿಧಿಗಳನ್ನು ಹೇಗೆ ಹಂಚಿಕೆ ಮಾಡಬೇಕೆಂದು ಸದಸ್ಯರು ಸಾಮೂಹಿಕವಾಗಿ ನಿರ್ಧರಿಸುತ್ತಾರೆ. DAO ನ ನಿಧಿಗಳನ್ನು ಹಂಚಿಕೆ ಮಾಡುವ ವಿಧಾನಗಳು ಬೌಂಟಿಗಳು, ಸಂಬಳಗಳಿಂದ ಹಿಡಿದು ಕೆಲಸಕ್ಕೆ ಪ್ರತಿಫಲ ನೀಡಲು ಆಂತರಿಕ ಕರೆನ್ಸಿಯಂತಹ ಇನ್ನೂ ವಿಚಿತ್ರ ಕಾರ್ಯವಿಧಾನಗಳವರೆಗೆ ವಿಸ್ತರಿಸಬಹುದು. ಇದು ಮೂಲಭೂತವಾಗಿ ಸಾಂಪ್ರದಾಯಿಕ ಕಂಪನಿ ಅಥವಾ ಲಾಭೋದ್ದೇಶವಿಲ್ಲದ ಕಾನೂನು ಬಲೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ ಆದರೆ ಜಾರಿಗಾಗಿ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಬ್ಲಾಕ್ಚೈನ್ ತಂತ್ರಜ್ಞಾನವನ್ನು ಮಾತ್ರ ಬಳಸುತ್ತದೆ. ಇಲ್ಲಿಯವರೆಗೆ DAOs ಸುತ್ತ ಹೆಚ್ಚಿನ ಚರ್ಚೆಗಳು ಲಾಭಾಂಶ-ಸ್ವೀಕರಿಸುವ ಷೇರುದಾರರು ಮತ್ತು ವ್ಯಾಪಾರ ಮಾಡಬಹುದಾದ ಷೇರುಗಳೊಂದಿಗೆ "ವಿಕೇಂದ್ರೀಕೃತ ಸ್ವಾಯತ್ತ ನಿಗಮ" (DAC) ದ "ಬಂಡವಾಳಶಾಹಿ" ಮಾದರಿಯ ಸುತ್ತಲೂ ಇವೆ; ಪರ್ಯಾಯ, ಬಹುಶಃ "ವಿಕೇಂದ್ರೀಕೃತ ಸ್ವಾಯತ್ತ ಸಮುದಾಯ" ಎಂದು ವಿವರಿಸಲಾಗಿದೆ, ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವಲ್ಲಿ ಎಲ್ಲಾ ಸದಸ್ಯರು ಸಮಾನ ಪಾಲನ್ನು ಹೊಂದಿರುತ್ತಾರೆ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ 67% ಸದಸ್ಯರು ಸದಸ್ಯರನ್ನು ಸೇರಿಸಲು ಅಥವಾ ತೆಗೆದುಹಾಕಲು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಕೇವಲ ಒಂದು ಸದಸ್ಯತ್ವವನ್ನು ಮಾತ್ರ ಹೊಂದಿರಬಹುದೆಂಬ ಅವಶ್ಯಕತೆಯನ್ನು ನಂತರ ಗುಂಪು ಒಟ್ಟಾಗಿ ಜಾರಿಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ.
ಒಂದು ಡಿಎಒ (DAO) ಅನ್ನು ಕೋಡ್ ಮಾಡಲು ಸಾಮಾನ್ಯ ರೂಪರೇಖೆ ಹೀಗಿದೆ. ಅತ್ಯಂತ ಸರಳವಾದ ವಿನ್ಯಾಸವು ಕೇವಲ ಸ್ವಯಂ-ಮಾರ್ಪಡಿಸುವ ಕೋಡ್ ಆಗಿದ್ದು, ಇದು ಮೂರನೇ ಎರಡರಷ್ಟು ಸದಸ್ಯರು ಒಂದು ಬದಲಾವಣೆಗೆ ಒಪ್ಪಿದರೆ ಬದಲಾಗುತ್ತದೆ. ಕೋಡ್ ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಅಪರಿವರ್ತನೀಯವಾಗಿದ್ದರೂ, ಇದನ್ನು ಸುಲಭವಾಗಿ ಸುತ್ತುಹಾಕಬಹುದು ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಪರಿವರ್ತನೀಯತೆಯನ್ನು ಹೊಂದಬಹುದು. ಇದನ್ನು ಕೋಡ್ನ ಭಾಗಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಒಪ್ಪಂದಗಳಲ್ಲಿ ಇರಿಸುವ ಮೂಲಕ ಮತ್ತು ಕರೆ ಮಾಡಬೇಕಾದ ಒಪ್ಪಂದಗಳ ವಿಳಾಸವನ್ನು ಮಾರ್ಪಡಿಸಬಹುದಾದ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುವ ಮೂಲಕ ಮಾಡಬಹುದು. ಅಂತಹ ಡಿಎಒ(DAO) ಒಪ್ಪಂದದ ಸರಳ ಅನುಷ್ಠಾನದಲ್ಲಿ, ಮೂರು ವ್ಯವಹಾರ ಪ್ರಕಾರಗಳಿರುತ್ತವೆ, ಅವುಗಳನ್ನು ವ್ಯವಹಾರದಲ್ಲಿ ಒದಗಿಸಲಾದ ಡೇಟಾದಿಂದ ವ್ಯತ್ಯಾಸಗೊಳಿಸಲಾಗುತ್ತದೆ:
[0,i,K,V
] ಸಂಗ್ರಹಣೆ ಸೂಚ್ಯಂಕK
ನಲ್ಲಿನ ವಿಳಾಸವನ್ನು ಮೌಲ್ಯV
ಗೆ ಬದಲಾಯಿಸಲು ಸೂಚ್ಯಂಕi
ಯೊಂದಿಗೆ ಪ್ರಸ್ತಾಪವನ್ನು ನೋಂದಾಯಿಸಲು[1,i]
ಪ್ರಸ್ತಾಪi
ಗೆ ಅನುಕೂಲವಾಗಿ ಮತವನ್ನು ನೋಂದಾಯಿಸಲು[2,i]
ಸಾಕಷ್ಟು ಮತಗಳು ಹಾಕಲ್ಪಟ್ಟಿದ್ದರೆ ಪ್ರಸ್ತಾಪi
ಅನ್ನು ಅಂತಿಮಗೊಳಿಸಲು
ನಂತರ ಒಪ್ಪಂದವು ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಖಂಡಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಇದು ಯಾರು ಅವುಗಳಿಗೆ ಮತ ಚಲಾಯಿಸಿದರು ಎಂಬುದರ ಪಟ್ಟಿಯೊಂದಿಗೆ, ಎಲ್ಲಾ ತೆರೆದ ಸಂಗ್ರಹಣೆ ಬದಲಾವಣೆಗಳ ದಾಖಲೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಎಲ್ಲಾ ಸದಸ್ಯರ ಪಟ್ಟಿಯನ್ನೂ ಹೊಂದಿರುತ್ತದೆ. ಯಾವುದೇ ಸಂಗ್ರಹಣೆ ಬದಲಾವಣೆಗೆ ಮೂರನೇ ಎರಡರಷ್ಟು ಸದಸ್ಯರು ಮತ ಚಲಾಯಿಸಿದಾಗ, ಅಂತಿಮಗೊಳಿಸುವ ವ್ಯವಹಾರವು ಬದಲಾವಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಹೆಚ್ಚು ಸುಧಾರಿತ ಚೌಕಟ್ಟು ವ್ಯವಹಾರವನ್ನು ಕಳುಹಿಸುವುದು, ಸದಸ್ಯರನ್ನು ಸೇರಿಸುವುದು ಮತ್ತು ತೆಗೆದುಹಾಕುವುದು ಮುಂತಾದ ವೈಶಿಷ್ಟ್ಯಗಳಿಗಾಗಿ ಅಂತರ್ನಿರ್ಮಿತ ಮತದಾನ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಮತ್ತು ದ್ರವ ಪ್ರಜಾಪ್ರಭುತ್ವ(opens in a new tab) ಶೈಲಿಯ ಮತ ನಿಯೋಜನೆಯನ್ನು ಸಹ ಒದಗಿಸಬಹುದು (ಅಂದರೆ, ಯಾರಾದರೂ ತಮಗಾಗಿ ಮತ ಚಲಾಯಿಸಲು ಯಾರನ್ನಾದರೂ ನಿಯೋಜಿಸಬಹುದು, ಮತ್ತು ನಿಯೋಜನೆಯು ಪರಿವರ್ತನೀಯವಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ A ಯು B ಯನ್ನು ನಿಯೋಜಿಸಿದರೆ ಮತ್ತು B ಯು C ಯನ್ನು ನಿಯೋಜಿಸಿದರೆ, C ಯು A ಯ ಮತವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ). ಈ ವಿನ್ಯಾಸವು ಡಿಎಒ(DAO) ಅನ್ನು ವಿಕೇಂದ್ರೀಕೃತ ಸಮುದಾಯವಾಗಿ ಸಾವಯವವಾಗಿ ಬೆಳೆಯಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಜನರು ಕ್ರಮೇಣ ಯಾರು ಸದಸ್ಯರಾಗಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವ ಕಾರ್ಯವನ್ನು ತಜ್ಞರಿಗೆ ವಹಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಆದರೆ "ಪ್ರಸ್ತುತ ವ್ಯವಸ್ಥೆ"ಯಲ್ಲಿನಂತೆ ಅಲ್ಲದೆ, ವೈಯಕ್ತಿಕ ಸಮುದಾಯ ಸದಸ್ಯರು ತಮ್ಮ ಹೊಂದಾಣಿಕೆಗಳನ್ನು ಬದಲಾಯಿಸಿದಂತೆ ತಜ್ಞರು ಸಮಯದೊಂದಿಗೆ ಸುಲಭವಾಗಿ ಹೊರಹೋಗಬಹುದು ಮತ್ತು ಒಳಬರಬಹುದು.
ವಿಕೇಂದ್ರೀಕೃತ ಕಾರ್ಪೊರೇಷನ್ಗೆ ಪರ್ಯಾಯ ಮಾದರಿಯು ಹೀಗಿದೆ, ಇಲ್ಲಿ ಯಾವುದೇ ಖಾತೆಯು ಶೂನ್ಯ ಅಥವಾ ಹೆಚ್ಚಿನ ಷೇರುಗಳನ್ನು ಹೊಂದಿರಬಹುದು, ಮತ್ತು ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳಲು ಮೂರನೇ ಎರಡರಷ್ಟು ಷೇರುಗಳ ಅಗತ್ಯವಿದೆ. ಸಂಪೂರ್ಣ ಚೌಕಟ್ಟು ಆಸ್ತಿ ನಿರ್ವಹಣಾ ಕಾರ್ಯಕ್ಷಮತೆ, ಷೇರುಗಳನ್ನು ಖರೀದಿಸಲು ಅಥವಾ ಮಾರಾಟ ಮಾಡಲು ಕೊಡುಗೆ ನೀಡುವ ಸಾಮರ್ಥ್ಯ, ಮತ್ತು ಕೊಡುಗೆಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು (ಆದ್ಯತೆಯ ಮೇರೆಗೆ ಒಪ್ಪಂದದೊಳಗೆ ಆದೇಶ-ಹೊಂದಾಣಿಕೆ ಕಾರ್ಯವಿಧಾನದೊಂದಿಗೆ) ಒಳಗೊಂಡಿರುತ್ತದೆ. ದ್ರವ ಪ್ರಜಾಪ್ರಭುತ್ವ ಶೈಲಿಯಲ್ಲಿ ನಿಯೋಜನೆಯೂ ಇರುತ್ತದೆ, "ನಿರ್ದೇಶಕರ ಮಂಡಳಿ" ಎಂಬ ಪರಿಕಲ್ಪನೆಯನ್ನು ಸಾಮಾನ್ಯೀಕರಿಸುತ್ತದೆ.
ಹೆಚ್ಚಿನ ಅನ್ವಯಿಕೆಗಳು
1. ಉಳಿತಾಯ ವಾಲೆಟ್ಗಳು. ಆಲಿಸ್ ತನ್ನ ನಿಧಿಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಇರಿಸಲು ಬಯಸುತ್ತಾಳೆ ಎಂದು ಭಾವಿಸೋಣ, ಆದರೆ ಅವಳು ತನ್ನ ಖಾಸಗಿ ಕೀಲಿಯನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಅಥವಾ ಯಾರಾದರೂ ಅದನ್ನು ಹ್ಯಾಕ್ ಮಾಡುವ ಬಗ್ಗೆ ಚಿಂತಿತಳಾಗಿದ್ದಾಳೆ. ಅವಳು ಬಾಬ್, ಒಂದು ಬ್ಯಾಂಕ್ನೊಂದಿಗೆ ಈ ಕೆಳಗಿನಂತೆ ಒಂದು ಒಪ್ಪಂದದಲ್ಲಿ ಎಥೆರಿಯಮ್ ಅನ್ನು ಹಾಕುತ್ತಾಳೆ:
- ಆಲಿಸ್ ಮಾತ್ರ ಪ್ರತಿದಿನ ನಿಧಿಗಳ ಗರಿಷ್ಠ 1% ಅನ್ನು ಹಿಂಪಡೆಯಬಹುದು.
- ಬಾಬ್ ಮಾತ್ರ ಪ್ರತಿದಿನ ನಿಧಿಗಳ ಗರಿಷ್ಠ 1% ಅನ್ನು ಹಿಂಪಡೆಯಬಹುದು, ಆದರೆ ಆಲಿಸ್ ತನ್ನ ಕೀಲಿಯೊಂದಿಗೆ ವ್ಯವಹಾರ ಮಾಡಿ ಈ ಸಾಮರ್ಥ್ಯವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದ್ದಾಳೆ.
- ಆಲಿಸ್ ಮತ್ತು ಬಾಬ್ ಒಟ್ಟಿಗೆ ಏನನ್ನಾದರೂ ಹಿಂಪಡೆಯಬಹುದು.
ಸಾಮಾನ್ಯವಾಗಿ, ಪ್ರತಿದಿನ 1% ಆಲಿಸ್ಗೆ ಸಾಕಾಗುತ್ತದೆ, ಮತ್ತು ಆಲಿಸ್ ಹೆಚ್ಚು ಹಿಂಪಡೆಯಲು ಬಯಸಿದರೆ ಅವಳು ಸಹಾಯಕ್ಕಾಗಿ ಬಾಬ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು. ಆಲಿಸ್ನ ಕೀಲಿಯನ್ನು ಹ್ಯಾಕ್ ಮಾಡಿದರೆ, ಅವಳು ನಿಧಿಗಳನ್ನು ಹೊಸ ಒಪ್ಪಂದಕ್ಕೆ ಸ್ಥಳಾಂತರಿಸಲು ಬಾಬ್ನ ಬಳಿಗೆ ಓಡುತ್ತಾಳೆ. ಅವಳು ತನ್ನ ಕೀಲಿಯನ್ನು ಕಳೆದುಕೊಂಡರೆ, ಬಾಬ್ ಕೊನೆಗೆ ನಿಧಿಗಳನ್ನು ಹೊರತೆಗೆಯುತ್ತಾನೆ. ಬಾಬ್ ದುರುದ್ದೇಶಪೂರಿತನಾಗಿ ಕಂಡುಬಂದರೆ, ಅವಳು ಅವನ ಹಿಂಪಡೆಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು.
2. ಬೆಳೆ ವಿಮೆ. ಯಾವುದೇ ಬೆಲೆ ಸೂಚ್ಯಂಕದ ಬದಲು ಹವಾಮಾನದ ಡೇಟಾ ಫೀಡ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಹಣಕಾಸು ಡೆರಿವೇಟಿವ್ಸ್ ಒಪ್ಪಂದವನ್ನು ಸುಲಭವಾಗಿ ಮಾಡಬಹುದು. ಐಯೋವಾದ ರೈತನು ಐಯೋವಾದಲ್ಲಿನ ಮಳೆಯ ಪ್ರಮಾಣದ ಆಧಾರದ ಮೇಲೆ ವಿಪರೀತವಾಗಿ ಹಣ ಪಾವತಿಸುವ ಡೆರಿವೇಟಿವ್ ಅನ್ನು ಖರೀದಿಸಿದರೆ, ಬರಗಾಲ ಬಂದರೆ ರೈತನಿಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹಣ ಸಿಗುತ್ತದೆ ಮತ್ತು ಸಾಕಷ್ಟು ಮಳೆ ಬಂದರೆ ರೈತನು ಸಂತೋಷಪಡುತ್ತಾನೆ ಏಕೆಂದರೆ ಅವನ ಬೆಳೆಗಳು ಚೆನ್ನಾಗಿ ಬೆಳೆಯುತ್ತವೆ. ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ನೈಸರ್ಗಿಕ ವಿಪತ್ತು ವಿಮೆಗೆ ವಿಸ್ತರಿಸಬಹುದು.
3. ವಿಕೇಂದ್ರೀಕೃತ ಡೇಟಾ ಫೀಡ್. ಹಣಕಾಸು ವ್ಯತ್ಯಾಸ ಒಪ್ಪಂದಗಳಿಗಾಗಿ, "ಶೆಲಿಂಗ್ಕಾಯಿನ್"(opens in a new tab) ಎಂಬ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಡೇಟಾ ಫೀಡ್ ಅನ್ನು ವಿಕೇಂದ್ರೀಕರಿಸುವುದು ವಾಸ್ತವವಾಗಿ ಸಾಧ್ಯವಾಗಬಹುದು. ಶೆಲಿಂಗ್ಕಾಯಿನ್ ಮೂಲತಃ ಹೀಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: N ಪಕ್ಷಗಳೆಲ್ಲವೂ ನೀಡಲಾದ ಡೇಟಮ್ನ ಮೌಲ್ಯವನ್ನು (ಉದಾ. ETH/USD ಬೆಲೆ) ವ್ಯವಸ್ಥೆಗೆ ಹಾಕುತ್ತವೆ, ಮೌಲ್ಯಗಳನ್ನು ವಿಂಗಡಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು 25ನೇ ಮತ್ತು 75ನೇ ಶತಮಾನದ ನಡುವೆ ಇರುವ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಬಹುಮಾನವಾಗಿ ಒಂದು ಟೋಕನ್ ಸಿಗುತ್ತದೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಉಳಿದವರು ನೀಡುವ ಉತ್ತರವನ್ನೇ ನೀಡಲು ಪ್ರೇರಣೆ ಹೊಂದಿರುತ್ತಾರೆ, ಮತ್ತು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಆಟಗಾರರು ವಾಸ್ತವವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳಬಹುದಾದ ಏಕೈಕ ಮೌಲ್ಯವೆಂದರೆ ಸ್ಪಷ್ಟವಾದ ಡೀಫಾಲ್ಟ್: ಸತ್ಯ. ಇದು ಸೈದ್ಧಾಂತಿಕವಾಗಿ ETH/USD ಬೆಲೆ, ಬರ್ಲಿನ್ನಲ್ಲಿನ ತಾಪಮಾನ ಅಥವಾ ನಿರ್ದಿಷ್ಟ ಕಠಿಣ ಗಣನೆಯ ಫಲಿತಾಂಶವನ್ನು ಸೇರಿದಂತೆ ಯಾವುದೇ ಸಂಖ್ಯೆಯ ಮೌಲ್ಯಗಳನ್ನು ಒದಗಿಸಬಹುದಾದ ವಿಕೇಂದ್ರೀಕೃತ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ.
4. ಸ್ಮಾರ್ಟ್ ಬಹು-ಸಹಿ ಎಸ್ಕ್ರೋ. ಬಿಟ್ಕಾಯಿನ್ ಬಹು-ಸಹಿ ವ್ಯವಹಾರ ಒಪ್ಪಂದಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಇಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ನೀಡಲಾದ ಐದು ಕೀಲಿಗಳಲ್ಲಿ ಮೂರು ನಿಧಿಗಳನ್ನು ಖರ್ಚು ಮಾಡಬಹುದು. ಎಥೆರಿಯಮ್ ಹೆಚ್ಚಿನ ಗ್ರಾನುಲಾರಿಟಿಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ; ಉದಾಹರಣೆಗೆ, ಐದರಲ್ಲಿ ನಾಲ್ಕು ಎಲ್ಲವನ್ನೂ ಖರ್ಚು ಮಾಡಬಹುದು, ಐದರಲ್ಲಿ ಮೂರು ಪ್ರತಿದಿನ 10% ವರೆಗೆ ಖರ್ಚು ಮಾಡಬಹುದು, ಮತ್ತು ಐದರಲ್ಲಿ ಎರಡು ಪ್ರತಿದಿನ 0.5% ವರೆಗೆ ಖರ್ಚು ಮಾಡಬಹುದು. ಇದಲ್ಲದೆ, ಎಥೆರಿಯಮ್ ಬಹು-ಸಹಿಯು ಅಸಮಕಾಲಿಕ ಆಗಿದೆ - ಎರಡು ಪಕ್ಷಗಳು ತಮ್ಮ ಸಹಿಗಳನ್ನು ಬೇರೆ ಬೇರೆ ಸಮಯದಲ್ಲಿ ಬ್ಲಾಕ್ಚೈನ್ನಲ್ಲಿ ನೋಂದಾಯಿಸಬಹುದು ಮತ್ತು ಕೊನೆಯ ಸಹಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವ್ಯವಹಾರವನ್ನು ಕಳುಹಿಸುತ್ತದೆ.
5. ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್. EVM ತಂತ್ರಜ್ಞಾನವನ್ನು ಪರಿಶೀಲಿಸಬಹುದಾದ ಕಂಪ್ಯೂಟಿಂಗ್ ಪರಿಸರವನ್ನು ರಚಿಸಲು ಸಹ ಬಳಸಬಹುದು, ಇದು ಬಳಕೆದಾರರು ಇತರರನ್ನು ಕಂಪ್ಯೂಟೇಶನ್ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಕೇಳಲು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಆಯ್ದ ಚೆಕ್ಪಾಯಿಂಟ್ಗಳಲ್ಲಿ ಕಂಪ್ಯೂಟೇಶನ್ಗಳನ್ನು ಸರಿಯಾಗಿ ಮಾಡಲಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ಐಚ್ಛಿಕವಾಗಿ ಪುರಾವೆಗಳನ್ನು ಕೇಳಬಹುದು. ಇದು ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಮಾರುಕಟ್ಟೆಯ ರಚನೆಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಇಲ್ಲಿ ಯಾವುದೇ ಬಳಕೆದಾರರು ತಮ್ಮ ಡೆಸ್ಕ್ಟಾಪ್, ಲ್ಯಾಪ್ಟಾಪ್ ಅಥವಾ ವಿಶೇಷ ಸರ್ವರ್ನೊಂದಿಗೆ ಭಾಗವಹಿಸಬಹುದು, ಮತ್ತು ಸ್ಪಾಟ್-ಚೆಕಿಂಗ್ ಜೊತೆಗೆ ಭದ್ರತಾ ಠೇವಣಿಗಳನ್ನು ವ್ಯವಸ್ಥೆಯು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಬಳಸಬಹುದು (ಅಂದರೆ, ನೋಡ್ಗಳು ಲಾಭದಾಯಕವಾಗಿ ಮೋಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ). ಇಂತಹ ವ್ಯವಸ್ಥೆಯು ಎಲ್ಲಾ ಕಾರ್ಯಗಳಿಗೂ ಸೂಕ್ತವಾಗಿರದಿರಬಹುದು; ಉದಾಹರಣೆಗೆ, ಅಂತರ-ಪ್ರಕ್ರಿಯೆ ಸಂವಹನದ ಉನ್ನತ ಮಟ್ಟದ ಅಗತ್ಯವಿರುವ ಕಾರ್ಯಗಳನ್ನು ದೊಡ್ಡ ನೋಡ್ಗಳ ಕ್ಲೌಡ್ನಲ್ಲಿ ಸುಲಭವಾಗಿ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಇತರ ಕಾರ್ಯಗಳು ಸಮಾನಾಂತರಗೊಳಿಸಲು ತುಂಬಾ ಸುಲಭವಾಗಿವೆ; SETI@home, folding@home ಮತ್ತು ಆನುವಂಶಿಕ ಅಲ್ಗಾರಿದಮ್ಗಳಂತಹ ಯೋಜನೆಗಳನ್ನು ಅಂತಹ ವೇದಿಕೆಯ ಮೇಲೆ ಸುಲಭವಾಗಿ ಅನುಷ್ಠಾನಗೊಳಿಸಬಹುದು.
6. ಸಮಾನರಿಂದ-ಸಮಾನರಿಗೆ ಜೂಜು. ಫ್ರಾಂಕ್ ಸ್ಟಜಾನೋ ಮತ್ತು ರಿಚರ್ಡ್ ಕ್ಲೇಟನ್ರ ಸೈಬರ್ಡೈಸ್ನಂತಹ(opens in a new tab) ಯಾವುದೇ ಸಂಖ್ಯೆಯ ಸಮಾನರಿಂದ-ಸಮಾನರಿಗೆ ಜೂಜಿನ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಎಥೆರಿಯಮ್ ಬ್ಲಾಕ್ಚೈನ್ನಲ್ಲಿ ಅನುಷ್ಠಾನಗೊಳಿಸಬಹುದು. ಅತ್ಯಂತ ಸರಳ ಜೂಜಿನ ಪ್ರೋಟೋಕಾಲ್ ವಾಸ್ತವವಾಗಿ ಮುಂದಿನ ಬ್ಲಾಕ್ ಹ್ಯಾಶ್ನ ವ್ಯತ್ಯಾಸಕ್ಕಾಗಿ ಒಂದು ಒಪ್ಪಂದವಾಗಿದೆ, ಮತ್ತು ಅಲ್ಲಿಂದ ಹೆಚ್ಚು ಸುಧಾರಿತ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು, ಇದರಿಂದ ಕಡಿಮೆ ಶುಲ್ಕ ಮತ್ತು ಮೋಸ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವಿಲ್ಲದ ಜೂಜಿನ ಸೇವೆಗಳನ್ನು ಸೃಷ್ಟಿಸಬಹುದು.
7. ಮುನ್ಸೂಚನೆ ಮಾರುಕಟ್ಟೆಗಳು. ಒಂದು ಆರಾಕಲ್ ಅಥವಾ ಶೆಲಿಂಗ್ಕಾಯಿನ್ ಒದಗಿಸಿದರೆ, ಮುನ್ಸೂಚನೆ ಮಾರುಕಟ್ಟೆಗಳನ್ನು ಸುಲಭವಾಗಿ ಅನುಷ್ಠಾನಗೊಳಿಸಬಹುದು, ಮತ್ತು ಮುನ್ಸೂಚನೆ ಮಾರುಕಟ್ಟೆಗಳು ಶೆಲಿಂಗ್ಕಾಯಿನ್ನೊಂದಿಗೆ ವಿಕೇಂದ್ರೀಕೃತ ಸಂಸ್ಥೆಗಳಿಗೆ ಆಡಳಿತ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ಫ್ಯೂಟಾರ್ಕಿಯ(opens in a new tab) ಮೊದಲ ಮುಖ್ಯವಾಹಿನಿ ಅಪ್ಲಿಕೇಶನ್ ಆಗುವ ಸಾಧ್ಯತೆ ಇದೆ.
8. ಆನ್-ಚೈನ್ ವಿಕೇಂದ್ರೀಕೃತ ಮಾರುಕಟ್ಟೆಗಳು, ಗುರುತು ಮತ್ತು ಖ್ಯಾತಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಆಧಾರವಾಗಿ ಬಳಸಿಕೊಂಡು.
ಇತರೆ ವಿಷಯಗಳು ಮತ್ತು ಕಾಳಜಿಗಳು
ಮಾರ್ಪಡಿಸಿದ GHOST ಅನುಷ್ಠಾನ
"ಗ್ರೀಡಿ ಹೆವಿಯೆಸ್ಟ್ ಆಬ್ಸರ್ವ್ಡ್ ಸಬ್ಟ್ರೀ" (GHOST) ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಯೊನಾತನ್ ಸೊಂಪೊಲಿನ್ಸ್ಕಿ ಮತ್ತು ಅವಿವ್ ಜೋಹರ್ ಅವರು 2013ರ ಡಿಸೆಂಬರ್ನಲ್ಲಿ(opens in a new tab) ಮೊದಲು ಪರಿಚಯಿಸಿದರು. GHOST ಹಿಂದಿನ ಪ್ರೇರಣೆ ಏನೆಂದರೆ, ವೇಗವಾದ ದೃಢೀಕರಣ ಸಮಯವನ್ನು ಹೊಂದಿರುವ ಬ್ಲಾಕ್ಚೈನ್ಗಳು ಪ್ರಸ್ತುತ ಹೆಚ್ಚಿನ ನಿಷ್ಫಲ ದರದಿಂದಾಗಿ ಕಡಿಮೆ ಭದ್ರತೆಯನ್ನು ಅನುಭವಿಸುತ್ತಿವೆ - ಏಕೆಂದರೆ ಬ್ಲಾಕ್ಗಳು ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಹರಡಲು ನಿರ್ದಿಷ್ಟ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ, ಒಂದು ವೇಳೆ ಮೈನರ್ A ಒಂದು ಬ್ಲಾಕ್ ಅನ್ನು ಮೈನ್ ಮಾಡಿದರೆ ಮತ್ತು ನಂತರ ಮೈನರ್ B ಮೈನರ್ A ಯ ಬ್ಲಾಕ್ B ಗೆ ಹರಡುವ ಮೊದಲು ಮತ್ತೊಂದು ಬ್ಲಾಕ್ ಅನ್ನು ಮೈನ್ ಮಾಡಿದರೆ, ಮೈನರ್ B ಯ ಬ್ಲಾಕ್ ವ್ಯರ್ಥವಾಗುತ್ತದೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಭದ್ರತೆಗೆ ಕೊಡುಗೆ ನೀಡುವುದಿಲ್ಲ. ಇದಲ್ಲದೆ, ಒಂದು ಕೇಂದ್ರೀಕರಣ ಸಮಸ್ಯೆ ಇದೆ: ಒಂದು ವೇಳೆ ಮೈನರ್ A 30% ಹ್ಯಾಶ್ಪವರ್ ಹೊಂದಿರುವ ಮೈನಿಂಗ್ ಪೂಲ್ ಆಗಿದ್ದರೆ ಮತ್ತು B 10% ಹ್ಯಾಶ್ಪವರ್ ಹೊಂದಿದ್ದರೆ, A ಗೆ 70% ಸಮಯದಲ್ಲಿ ನಿಷ್ಫಲ ಬ್ಲಾಕ್ ಉತ್ಪಾದಿಸುವ ಅಪಾಯವಿರುತ್ತದೆ (ಏಕೆಂದರೆ ಉಳಿದ 30% ಸಮಯದಲ್ಲಿ A ಕೊನೆಯ ಬ್ಲಾಕ್ ಅನ್ನು ಉತ್ಪಾದಿಸಿರುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಮೈನಿಂಗ್ ಡೇಟಾವನ್ನು ತಕ್ಷಣವೇ ಪಡೆಯುತ್ತದೆ) ಆದರೆ B ಗೆ 90% ಸಮಯದಲ್ಲಿ ನಿಷ್ಫಲ ಬ್ಲಾಕ್ ಉತ್ಪಾದಿಸುವ ಅಪಾಯವಿರುತ್ತದೆ. ಹೀಗಾಗಿ, ಬ್ಲಾಕ್ ಅಂತರವು ನಿಷ್ಫಲ ದರವು ಹೆಚ್ಚಾಗುವಷ್ಟು ಕಡಿಮೆಯಾಗಿದ್ದರೆ, A ತನ್ನ ಗಾತ್ರದ ಕಾರಣದಿಂದಾಗಿಯೇ ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚು ದಕ್ಷವಾಗಿರುತ್ತದೆ. ಈ ಎರಡು ಪರಿಣಾಮಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸಿದಾಗ, ವೇಗವಾಗಿ ಬ್ಲಾಕ್ಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಬ್ಲಾಕ್ಚೈನ್ಗಳು ಒಂದು ಮೈನಿಂಗ್ ಪೂಲ್ ನೆಟ್ವರ್ಕ್ ಹ್ಯಾಶ್ಪವರ್ನ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಶೇಕಡಾವಾರು ಹೊಂದಿರುವಂತೆ ಮಾಡುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು, ಇದರಿಂದ ಅದು ಮೈನಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯ ಮೇಲೆ ವಾಸ್ತವಿಕ ನಿಯಂತ್ರಣ ಹೊಂದಿರುತ್ತದೆ.
ಸೊಂಪೊಲಿನ್ಸ್ಕಿ ಮತ್ತು ಜೋಹರ್ ವಿವರಿಸಿದಂತೆ, GHOST ನೆಟ್ವರ್ಕ್ ಭದ್ರತೆ ನಷ್ಟದ ಮೊದಲ ಸಮಸ್ಯೆಯನ್ನು ಯಾವ ಸರಪಳಿ "ಅತ್ಯಂತ ಉದ್ದವಾದದ್ದು" ಎಂಬುದರ ಲೆಕ್ಕಾಚಾರದಲ್ಲಿ ನಿಷ್ಫಲ ಬ್ಲಾಕ್ಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಪರಿಹರಿಸುತ್ತದೆ; ಅಂದರೆ, ಕೇವಲ ಬ್ಲಾಕ್ನ ಮೂಲ ಮತ್ತು ಮುಂದಿನ ಪೂರ್ವಜರು ಮಾತ್ರವಲ್ಲದೆ, ಬ್ಲಾಕ್ನ ಪೂರ್ವಜರ ನಿಷ್ಫಲ ಸಂತತಿಗಳನ್ನು ಸಹ (ಎಥೆರಿಯಮ್ ಭಾಷೆಯಲ್ಲಿ, "ಅಂಕಲ್ಗಳು") ಯಾವ ಬ್ಲಾಕ್ ಅತ್ಯಂತ ದೊಡ್ಡ ಒಟ್ಟು ಪ್ರೂಫ್-ಆಫ್-ವರ್ಕ್ ಬೆಂಬಲವನ್ನು ಹೊಂದಿದೆ ಎಂಬುದರ ಲೆಕ್ಕಾಚಾರಕ್ಕೆ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಕೇಂದ್ರೀಕರಣ ಪಕ್ಷಪಾತದ ಎರಡನೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ಸೊಂಪೊಲಿನ್ಸ್ಕಿ ಮತ್ತು ಜೋಹರ್ ವಿವರಿಸಿದ ಪ್ರೋಟೋಕಾಲ್ಗಿಂತ ಮುಂದೆ ಹೋಗುತ್ತೇವೆ, ಮತ್ತು ನಿಷ್ಫಲ ಬ್ಲಾಕ್ಗಳಿಗೂ ಬಹುಮಾನಗಳನ್ನು ನೀಡುತ್ತೇವೆ: ನಿಷ್ಫಲ ಬ್ಲಾಕ್ ತನ್ನ ಮೂಲ ಬಹುಮಾನದ 87.5% ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ನಿಷ್ಫಲ ಬ್ಲಾಕ್ ಅನ್ನು ಒಳಗೊಳ್ಳುವ ಭಾವನ ಉಳಿದ 12.5% ಪಡೆಯುತ್ತದೆ. ಆದಾಗ್ಯೂ, ವ್ಯವಹಾರ ಶುಲ್ಕಗಳನ್ನು ಅಂಕಲ್ಗಳಿಗೆ ವಿಧಿಸಲಾಗುವುದಿಲ್ಲ.
ಎಥೆರಿಯಮ್ GHOST ನ ಸರಳೀಕೃತ ಆವೃತ್ತಿಯನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುತ್ತದೆ, ಇದು ಕೇವಲ ಏಳು ಹಂತಗಳವರೆಗೆ ಹೋಗುತ್ತದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ, ಇದನ್ನು ಹೀಗೆ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ:
- ಒಂದು ಬ್ಲಾಕ್ ಒಂದು ಮೂಲವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು, ಮತ್ತು ಅದು 0 ಅಥವಾ ಹೆಚ್ಚಿನ ಅಂಕಲ್ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು
- ಬ್ಲಾಕ್ B ನಲ್ಲಿ ಸೇರಿಸಲಾದ ಅಂಕಲ್ ಈ ಕೆಳಗಿನ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರಬೇಕು:
- ಅದು B ನ kನೇ ಪೀಳಿಗೆಯ ಪೂರ್ವಜನ ನೇರ ಮಗುವಾಗಿರಬೇಕು, ಇಲ್ಲಿ
2 <= k <= 7
. - ಅದು B ನ ಪೂರ್ವಜವಾಗಿರಲು ಸಾಧ್ಯವಿಲ್ಲ
- ಒಂದು ಅಂಕಲ್ ಮಾನ್ಯ ಬ್ಲಾಕ್ ಹೆಡರ್ ಆಗಿರಬೇಕು, ಆದರೆ ಹಿಂದೆ ಪರಿಶೀಲಿಸಲ್ಪಟ್ಟ ಅಥವಾ ಮಾನ್ಯ ಬ್ಲಾಕ್ ಆಗಿರಬೇಕಾಗಿಲ್ಲ
- ಒಂದು ಅಂಕಲ್ ಹಿಂದಿನ ಬ್ಲಾಕ್ಗಳಲ್ಲಿ ಸೇರಿಸಲಾದ ಎಲ್ಲಾ ಅಂಕಲ್ಗಳಿಂದ ಮತ್ತು ಅದೇ ಬ್ಲಾಕ್ನಲ್ಲಿ ಸೇರಿಸಲಾದ ಇತರ ಎಲ್ಲಾ ಅಂಕಲ್ಗಳಿಂದ ಭಿನ್ನವಾಗಿರಬೇಕು (ಎರಡು ಬಾರಿ-ಸೇರ್ಪಡೆ ಇಲ್ಲ)
- ಅದು B ನ kನೇ ಪೀಳಿಗೆಯ ಪೂರ್ವಜನ ನೇರ ಮಗುವಾಗಿರಬೇಕು, ಇಲ್ಲಿ
- ಬ್ಲಾಕ್ B ನಲ್ಲಿನ ಪ್ರತಿ ಅಂಕಲ್ U ಗಾಗಿ, B ನ ಮೈನರ್ ತನ್ನ ಕಾಯಿನ್ಬೇಸ್ ಬಹುಮಾನಕ್ಕೆ ಹೆಚ್ಚುವರಿ 3.125% ಪಡೆಯುತ್ತಾನೆ ಮತ್ತು U ನ ಮೈನರ್ ಪ್ರಮಾಣಿತ ಕಾಯಿನ್ಬೇಸ್ ಬಹುಮಾನದ 93.75% ಪಡೆಯುತ್ತಾನೆ.
GHOST ನ ಈ ಸೀಮಿತ ಆವೃತ್ತಿಯನ್ನು, ಅಂಕಲ್ಗಳನ್ನು ಕೇವಲ 7 ಪೀಳಿಗೆಗಳವರೆಗೆ ಮಾತ್ರ ಸೇರಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ, ಎರಡು ಕಾರಣಗಳಿಗಾಗಿ ಬಳಸಲಾಯಿತು. ಮೊದಲನೆಯದಾಗಿ, ಅನಿಯಂತ್ರಿತ GHOST ನಿರ್ದಿಷ್ಟ ಬ್ಲಾಕ್ಗೆ ಯಾವ ಅಂಕಲ್ಗಳು ಮಾನ್ಯವಾಗಿವೆ ಎಂಬುದರ ಲೆಕ್ಕಾಚಾರದಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಕೀರ್ಣತೆಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತಿತ್ತು. ಎರಡನೆಯದಾಗಿ, ಎಥೆರಿಯಮ್ನಲ್ಲಿ ಬಳಸಲಾದ ಪರಿಹಾರದೊಂದಿಗೆ ಅನಿಯಂತ್ರಿತ GHOST, ಮೈನರ್ ಮುಖ್ಯ ಸರಪಳಿಯಲ್ಲಿ ಮೈನ್ ಮಾಡಲು ಮತ್ತು ಸಾರ್ವಜನಿಕ ಆಕ್ರಮಣಕಾರನ ಸರಪಳಿಯಲ್ಲಿ ಮೈನ್ ಮಾಡದಿರಲು ಇರುವ ಪ್ರೋತ್ಸಾಹವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ಶುಲ್ಕಗಳು
ಬ್ಲಾಕ್ಚೈನ್ನಲ್ಲಿ ಪ್ರಕಟಿಸಲಾದ ಪ್ರತಿ ವ್ಯವಹಾರವೂ ನೆಟ್ವರ್ಕ್ಗೆ ಅದನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡುವ ಮತ್ತು ಪರಿಶೀಲಿಸುವ ಅಗತ್ಯದ ವೆಚ್ಚವನ್ನು ವಿಧಿಸುವುದರಿಂದ, ದುರುಪಯೋಗವನ್ನು ತಡೆಯಲು ಕೆಲವು ನಿಯಂತ್ರಕ ಕ್ರಮಗಳ ಅಗತ್ಯವಿದೆ, ಸಾಮಾನ್ಯವಾಗಿ ವ್ಯವಹಾರ ಶುಲ್ಕಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿ ಬಳಸಲಾಗುವ ಡೀಫಾಲ್ಟ್ ವಿಧಾನವೆಂದರೆ ಸಂಪೂರ್ಣ ಸ್ವಯಂಪ್ರೇರಿತ ಶುಲ್ಕಗಳನ್ನು ಹೊಂದಿರುವುದು, ಮೈನರ್ಗಳು ದ್ವಾರಪಾಲಕರಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಮತ್ತು ಚಲನಶೀಲ ಕನಿಷ್ಠ ಮೊತ್ತಗಳನ್ನು ಹೊಂದಿಸಲು ಅವಲಂಬಿಸುವುದು. ಈ ವಿಧಾನವನ್ನು ಬಿಟ್ಕಾಯಿನ್ ಸಮುದಾಯದಲ್ಲಿ ಬಹಳ ಅನುಕೂಲಕರವಾಗಿ ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಏಕೆಂದರೆ ಇದು "ಮಾರುಕಟ್ಟೆ-ಆಧಾರಿತ", ಮೈನರ್ಗಳು ಮತ್ತು ವ್ಯವಹಾರ ಕಳುಹಿಸುವವರ ನಡುವಿನ ಪೂರೈಕೆ ಮತ್ತು ಬೇಡಿಕೆಯು ಬೆಲೆಯನ್ನು ನಿರ್ಧರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಆದರೆ ಈ ತರ್ಕದ ಸಾಲಿನೊಂದಿಗೆ ಸಮಸ್ಯೆ ಏನೆಂದರೆ, ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಯು ಮಾರುಕಟ್ಟೆಯಲ್ಲ; ಮೈನರ್ ಕಳುಹಿಸುವವರಿಗೆ ನೀಡುತ್ತಿರುವ ಸೇವೆಯಾಗಿ ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅರ್ಥೈಸಲು ಸಹಜವಾಗಿ ಆಕರ್ಷಕವಾಗಿದ್ದರೂ, ವಾಸ್ತವದಲ್ಲಿ ಮೈನರ್ ಸೇರಿಸುವ ಪ್ರತಿ ವ್ಯವಹಾರವನ್ನು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿರುವ ಪ್ರತಿ ನೋಡ್ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಯ ವೆಚ್ಚದ ಬಹುಪಾಲು ಮೂರನೇ ವ್ಯಕ್ತಿಗಳು ಭರಿಸುತ್ತಾರೆ ಮತ್ತು ಅದನ್ನು ಸೇರಿಸಬೇಕೇ ಬೇಡವೇ ಎಂಬ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವ ಮೈನರ್ ಭರಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಸಾಮಾನ್ಯ-ಸಂಪನ್ಮೂಲದ ದುರಂತ ಸಮಸ್ಯೆಗಳು ಸಂಭವಿಸುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು.
ಆದರೆ, ತಿಳಿದುಬಂದಂತೆ ಮಾರುಕಟ್ಟೆ-ಆಧಾರಿತ ಕ್ರಮದಲ್ಲಿನ ಈ ದೋಷವು, ಒಂದು ನಿರ್ದಿಷ್ಟ ಅಸಮರ್ಪಕ ಸರಳೀಕರಣ ಊಹೆಯನ್ನು ನೀಡಿದಾಗ, ಅದ್ಭುತವಾಗಿ ತನ್ನನ್ನು ತಾನೇ ರದ್ದುಗೊಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ವಾದವು ಹೀಗಿದೆ. ಊಹಿಸಿಕೊಳ್ಳಿ:
- ಒಂದು ವ್ಯವಹಾರವು
k
ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಅದನ್ನು ಸೇರಿಸುವ ಯಾವುದೇ ಮೈನರ್ಗೆkR
ಬಹುಮಾನವನ್ನು ನೀಡುತ್ತದೆ, ಇಲ್ಲಿR
ಅನ್ನು ಕಳುಹಿಸುವವರು ನಿಗದಿಪಡಿಸುತ್ತಾರೆ ಮತ್ತುk
ಮತ್ತುR
ಅನ್ನು ಮುಂಚಿತವಾಗಿ ಮೈನರ್ಗೆ (ಸುಮಾರಾಗಿ) ಗೋಚರಿಸಬಹುದು. - ಒಂದು ಕಾರ್ಯಾಚರಣೆಯು ಯಾವುದೇ ನೋಡ್ಗೆ
C
ಪ್ರಕ್ರಿಯೆ ವೆಚ್ಚವನ್ನು ಹೊಂದಿದೆ (ಅಂದರೆ ಎಲ್ಲಾ ನೋಡ್ಗಳು ಸಮಾನ ದಕ್ಷತೆಯನ್ನು ಹೊಂದಿವೆ) N
ಗಣಿಗಾರಿಕೆ ನೋಡ್ಗಳಿವೆ, ಪ್ರತಿಯೊಂದೂ ಸರಿಯಾಗಿ ಸಮಾನ ಪ್ರಕ್ರಿಯೆ ಶಕ್ತಿಯನ್ನು ಹೊಂದಿದೆ (ಅಂದರೆ ಒಟ್ಟು1/N
)- ಯಾವುದೇ ಗಣಿಗಾರಿಕೆ ರಹಿತ ಪೂರ್ಣ ನೋಡ್ಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ.
ನಿರೀಕ್ಷಿತ ಬಹುಮಾನವು ವೆಚ್ಚಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿದ್ದರೆ ಗಣಿಗಾರ ವ್ಯವಹಾರವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸಿದ್ಧನಾಗಿರುತ್ತಾನೆ. ಹೀಗಾಗಿ, ನಿರೀಕ್ಷಿತ ಬಹುಮಾನವು kR/N
ಆಗಿದೆ ಏಕೆಂದರೆ ಗಣಿಗಾರ ಮುಂದಿನ ಬ್ಲಾಕ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು 1/N
ಅವಕಾಶ ಹೊಂದಿದ್ದಾನೆ, ಮತ್ತು ಗಣಿಗಾರನಿಗೆ ಪ್ರಕ್ರಿಯೆ ವೆಚ್ಚವು ಕೇವಲ kC
ಆಗಿದೆ. ಆದ್ದರಿಂದ, ಗಣಿಗಾರರು kR/N > kC
, ಅಥವಾ R > NC
ಆಗಿರುವ ವ್ಯವಹಾರಗಳನ್ನು ಸೇರಿಸುತ್ತಾರೆ. R
ಕಳುಹಿಸುವವರು ಒದಗಿಸಿದ ಪ್ರತಿ-ಕಾರ್ಯಾಚರಣೆ ಶುಲ್ಕವಾಗಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ, ಮತ್ತು ಹೀಗಾಗಿ ಕಳುಹಿಸುವವರು ವ್ಯವಹಾರದಿಂದ ಪಡೆಯುವ ಲಾಭದ ಕನಿಷ್ಠ ಮಿತಿಯಾಗಿದೆ, ಮತ್ತು NC
ಒಂದು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಇಡೀ ನೆಟ್ವರ್ಕ್ಗೆ ಒಟ್ಟಾರೆ ವೆಚ್ಚವಾಗಿದೆ. ಆದ್ದರಿಂದ, ಗಣಿಗಾರರು ಒಟ್ಟು ಉಪಯುಕ್ತ ಲಾಭವು ವೆಚ್ಚವನ್ನು ಮೀರುವ ವ್ಯವಹಾರಗಳನ್ನು ಮಾತ್ರ ಸೇರಿಸಲು ಪ್ರೋತ್ಸಾಹ ಹೊಂದಿದ್ದಾರೆ.
ಆದಾಗ್ಯೂ, ವಾಸ್ತವದಲ್ಲಿ ಆ ಊಹೆಗಳಿಂದ ಹಲವಾರು ಮುಖ್ಯವಾದ ವ್ಯತ್ಯಾಸಗಳಿವೆ:
- ಮೈನರ್ ವ್ಯವಹಾರವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಇತರ ಪರಿಶೀಲನಾ ನೋಡ್ಗಳಿಗಿಂತ ಹೆಚ್ಚಿನ ವೆಚ್ಚವನ್ನು ಭರಿಸುತ್ತಾನೆ, ಏಕೆಂದರೆ ಹೆಚ್ಚುವರಿ ಪರಿಶೀಲನಾ ಸಮಯವು ಬ್ಲಾಕ್ ಹರಡುವಿಕೆಯನ್ನು ವಿಳಂಬಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಹೀಗಾಗಿ ಬ್ಲಾಕ್ ನಿಷ್ಫಲವಾಗುವ ಸಾಧ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
- ಗಣಿಗಾರಿಕೆ ರಹಿತ ಪೂರ್ಣ ನೋಡ್ಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ.
- ಗಣಿಗಾರಿಕೆ ಶಕ್ತಿಯ ವಿತರಣೆಯು ಅಭ್ಯಾಸದಲ್ಲಿ ತೀವ್ರವಾಗಿ ಅಸಮಾನತೆಯನ್ನು ಹೊಂದಬಹುದು.
- ನೆಟ್ವರ್ಕ್ಗೆ ಹಾನಿ ಉಂಟುಮಾಡುವುದನ್ನು ತಮ್ಮ ಉಪಯುಕ್ತತೆ ಕಾರ್ಯದಲ್ಲಿ ಒಳಗೊಂಡಿರುವ ಊಹಾಪೋಹಗಾರರು, ರಾಜಕೀಯ ಶತ್ರುಗಳು ಮತ್ತು ಹುಚ್ಚರು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದಾರೆ, ಮತ್ತು ಅವರು ತಮ್ಮ ವೆಚ್ಚವು ಇತರ ಪರಿಶೀಲನಾ ನೋಡ್ಗಳು ಪಾವತಿಸುವ ವೆಚ್ಚಕ್ಕಿಂತ ಬಹಳ ಕಡಿಮೆಯಾಗಿರುವ ಒಪ್ಪಂದಗಳನ್ನು ಚಾಣಾಕ್ಷತನದಿಂದ ರಚಿಸಬಹುದು.
(1) ಗಣಿಗಾರನಿಗೆ ಕಡಿಮೆ ವಹಿವಾಟುಗಳನ್ನು ಸೇರಿಸುವ ಪ್ರವೃತ್ತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ, ಮತ್ತು (2) NC
ಹೆಚ್ಚಾಗುತ್ತದೆ; ಆದ್ದರಿಂದ, ಈ ಎರಡು ಪರಿಣಾಮಗಳು ಕನಿಷ್ಠ ಭಾಗಶಃ ಪರಸ್ಪರ ರದ್ದುಗೊಳಿಸುತ್ತವೆ.ಹೇಗೆ?(opens in a new tab) (3) ಮತ್ತು (4) ಅವು ಪ್ರಮುಖ ಸಮಸ್ಯೆಗಳಾಗಿವೆ; ಅವುಗಳನ್ನು ಪರಿಹರಿಸಲು ನಾವು ಫ್ಲೋಟಿಂಗ್ ಕ್ಯಾಪ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ: ಯಾವುದೇ ಬ್ಲಾಕ್ ದೀರ್ಘಾವಧಿಯ ಘಾತೀಯ ಚಲಿಸುವ ಸರಾಸರಿಗಿಂತ BLK _ LIMIT _ FACTOR
ಪಟ್ಟು ಹೆಚ್ಚು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಹೊಂದಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಿರ್ದಿಷ್ಟವಾಗಿ:
blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)
BLK_LIMIT_FACTOR
ಮತ್ತು EMA_FACTOR
ಎಂಬುವು ಸ್ಥಿರಾಂಕಗಳಾಗಿದ್ದು, ಸದ್ಯಕ್ಕೆ 65536 ಮತ್ತು 1.5 ಕ್ಕೆ ಹೊಂದಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಮುಂದಿನ ವಿಶ್ಲೇಷಣೆಯ ನಂತರ ಬದಲಾಯಿಸಲ್ಪಡುವ ಸಾಧ್ಯತೆಯಿದೆ.
ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿ ದೊಡ್ಡ ಬ್ಲಾಕ್ ಗಾತ್ರಗಳನ್ನು ನಿರುತ್ಸಾಹಗೊಳಿಸುವ ಮತ್ತೊಂದು ಅಂಶವಿದೆ: ದೊಡ್ಡ ಗಾತ್ರದ ಬ್ಲಾಕ್ಗಳು ಹರಡಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಹೀಗಾಗಿ ನಿಷ್ಫಲವಾಗುವ ಹೆಚ್ಚಿನ ಸಾಧ್ಯತೆಯನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಎಥೆರಿಯಮ್ನಲ್ಲಿ, ಹೆಚ್ಚು ಇಂಧನ-ಬಳಕೆ ಮಾಡುವ ಬ್ಲಾಕ್ಗಳು ಸಹ ಹರಡಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಏಕೆಂದರೆ ಅವು ಭೌತಿಕವಾಗಿ ದೊಡ್ಡದಾಗಿರುವುದರಿಂದ ಮತ್ತು ಮಾನ್ಯಮಾಡಲು ವ್ಯವಹಾರ ಸ್ಥಿತಿ ಪರಿವರ್ತನೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವುದರಿಂದ. ಈ ವಿಳಂಬದ ನಿರುತ್ಸಾಹವು ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿ ಒಂದು ಮಹತ್ವದ ಪರಿಗಣನೆಯಾಗಿದೆ, ಆದರೆ GHOST ಪ್ರೋಟೋಕಾಲ್ನ ಕಾರಣದಿಂದಾಗಿ ಎಥೆರಿಯಮ್ನಲ್ಲಿ ಅಷ್ಟೊಂದು ಅಲ್ಲ; ಆದ್ದರಿಂದ, ನಿಯಂತ್ರಿತ ಬ್ಲಾಕ್ ಮಿತಿಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವುದು ಹೆಚ್ಚು ಸ್ಥಿರವಾದ ಮೂಲ ರೇಖೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಕಂಪ್ಯುಟೇಶನ್ ಮತ್ತು ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣತೆ
ಒಂದು ಮುಖ್ಯವಾದ ಟಿಪ್ಪಣಿ ಏನೆಂದರೆ ಎಥೆರಿಯಮ್ ವರ್ಚುವಲ್ ಮೆಷಿನ್ ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣವಾಗಿದೆ; ಇದರರ್ಥ EVM ಕೋಡ್ ಊಹಿಸಬಹುದಾದ ಯಾವುದೇ ಕಂಪ್ಯುಟೇಶನ್ ಅನ್ನು, ಅನಂತ ಲೂಪ್ಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಎನ್ಕೋಡ್ ಮಾಡಬಹುದು. EVM ಕೋಡ್ ಎರಡು ರೀತಿಯಲ್ಲಿ ಲೂಪಿಂಗ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ಕೋಡ್ನಲ್ಲಿ ಹಿಂದಿನ ಸ್ಥಳಕ್ಕೆ ಹಿಂತಿರುಗಲು ಪ್ರೋಗ್ರಾಂಗೆ ಅನುಮತಿಸುವ JUMP
ಸೂಚನೆ ಇದೆ, ಮತ್ತು ಷರತ್ತುಬದ್ಧ ಜಂಪಿಂಗ್ ಮಾಡಲು JUMPI
ಸೂಚನೆ ಇದೆ, ಇದು while x < 27: x = x * 2
ನಂತಹ ಹೇಳಿಕೆಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ಒಪ್ಪಂದಗಳು ಇತರ ಒಪ್ಪಂದಗಳನ್ನು ಕರೆಯಬಹುದು, ಸಂಭಾವ್ಯವಾಗಿ ರಿಕರ್ಷನ್ ಮೂಲಕ ಲೂಪಿಂಗ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಇದು ಸ್ವಾಭಾವಿಕವಾಗಿ ಒಂದು ಸಮಸ್ಯೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ: ದುರುದ್ದೇಶಪೂರಿತ ಬಳಕೆದಾರರು ಗಣಿಗಾರರು ಮತ್ತು ಪೂರ್ಣ ನೋಡ್ಗಳನ್ನು ಅನಂತ ಲೂಪ್ಗೆ ಪ್ರವೇಶಿಸುವಂತೆ ಒತ್ತಾಯಿಸುವ ಮೂಲಕ ಮೂಲಭೂತವಾಗಿ ಸ್ಥಗಿತಗೊಳಿಸಬಹುದೇ? ಈ ಸಮಸ್ಯೆಯು ಕಂಪ್ಯೂಟರ್ ವಿಜ್ಞಾನದಲ್ಲಿ ನಿಲುಗಡೆ ಸಮಸ್ಯೆ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಸಮಸ್ಯೆಯಿಂದ ಉದ್ಭವಿಸುತ್ತದೆ: ಸಾಮಾನ್ಯ ಸಂದರ್ಭದಲ್ಲಿ, ನೀಡಲಾದ ಪ್ರೋಗ್ರಾಂ ಎಂದಾದರೂ ನಿಲ್ಲುತ್ತದೆಯೇ ಇಲ್ಲವೇ ಎಂದು ಹೇಳಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ.
ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ವಿಭಾಗದಲ್ಲಿ ವಿವರಿಸಿದಂತೆ, ನಮ್ಮ ಪರಿಹಾರವು ವ್ಯವಹಾರವು ತೆಗೆದುಕೊಳ್ಳಲು ಅನುಮತಿಸಲಾದ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಕಂಪ್ಯುಟೇಶನಲ್ ಹಂತಗಳನ್ನು ಹೊಂದಿಸಬೇಕೆಂದು ಅಗತ್ಯಪಡಿಸುವ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡರೆ ಕಂಪ್ಯುಟೇಶನ್ ಅನನ್ನು ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಶುಲ್ಕಗಳನ್ನು ಇನ್ನೂ ಪಾವತಿಸಲಾಗುತ್ತದೆ. ಸಂದೇಶಗಳು ಅದೇ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ನಮ್ಮ ಪರಿಹಾರದ ಹಿಂದಿನ ಪ್ರೇರಣೆಯನ್ನು ತೋರಿಸಲು, ಈ ಕೆಳಗಿನ ಉದಾಹರಣೆಗಳನ್ನು ಪರಿಗಣಿಸಿ:
- ಒಬ್ಬ ಆಕ್ರಮಣಕಾರ ಅನಂತ ಲೂಪ್ ಅನ್ನು ರನ್ ಮಾಡುವ ಒಪ್ಪಂದವನ್ನು ರಚಿಸುತ್ತಾನೆ, ನಂತರ ಆ ಲೂಪ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ವ್ಯವಹಾರವನ್ನು ಮೈನರ್ಗೆ ಕಳುಹಿಸುತ್ತಾನೆ. ಮೈನರ್ ವ್ಯವಹಾರವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಾನೆ, ಅನಂತ ಲೂಪ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತಾನೆ, ಮತ್ತು ಅದು ಗ್ಯಾಸ್ ಖಾಲಿಯಾಗುವವರೆಗೆ ಕಾಯುತ್ತಾನೆ. ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ಇಂಧನ ಖಾಲಿಯಾಗಿ ಅರ್ಧದಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಎಂದರೂ, ವ್ಯವಹಾರವು ಇನ್ನೂ ಮಾನ್ಯವಾಗಿದೆ ಮತ್ತು ಗಣಿಗಾರ ಇನ್ನೂ ಪ್ರತಿ ಕಂಪ್ಯುಟೇಶನ್ ಹಂತಕ್ಕೆ ಆಕ್ರಮಣಕಾರನಿಂದ ಶುಲ್ಕವನ್ನು ಕ್ಲೈಮ್ ಮಾಡುತ್ತಾನೆ.
- ಒಬ್ಬ ಆಕ್ರಮಣಕಾರ ಬಹಳ ಉದ್ದವಾದ ಅನಂತ ಲೂಪ್ ಅನ್ನು ರಚಿಸುತ್ತಾನೆ, ಇದರ ಉದ್ದೇಶ ಗಣಿಗಾರನನ್ನು ಅಷ್ಟು ದೀರ್ಘ ಸಮಯದವರೆಗೆ ಕಂಪ್ಯೂಟಿಂಗ್ ಮಾಡುವಂತೆ ಒತ್ತಾಯಿಸುವುದು, ಕಂಪ್ಯುಟೇಶನ್ ಮುಗಿಯುವ ಹೊತ್ತಿಗೆ ಇನ್ನೂ ಕೆಲವು ಬ್ಲಾಕ್ಗಳು ಹೊರಬಂದಿರುತ್ತವೆ ಮತ್ತು ಗಣಿಗಾರ ಶುಲ್ಕವನ್ನು ಕ್ಲೈಮ್ ಮಾಡಲು ವ್ಯವಹಾರವನ್ನು ಸೇರಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಆಕ್ರಮಣಕಾರನು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ತೆಗೆದುಕೊಳ್ಳಬಹುದಾದ ಕಂಪ್ಯುಟೇಶನಲ್ ಹಂತಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸುವ
STARTGAS
ಗಾಗಿ ಮೌಲ್ಯವನ್ನು ಸಲ್ಲಿಸಬೇಕಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಂಪ್ಯುಟೇಶನ್ ಅತ್ಯಧಿಕ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಹಂತಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಗಣಿಗಾರ ಮುಂಚಿತವಾಗಿಯೇ ತಿಳಿದುಕೊಳ್ಳುತ್ತಾನೆ. - ಒಬ್ಬ ಆಕ್ರಮಣಕಾರನು
send(A,contract.storage[A]); contract.storage[A] = 0
ಎಂಬ ರೀತಿಯ ಕೋಡ್ ಹೊಂದಿರುವ ಒಂದು ಒಪ್ಪಂದವನ್ನು ನೋಡುತ್ತಾನೆ, ಮತ್ತು ಮೊದಲ ಹಂತವನ್ನು ಮಾತ್ರ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಕಾಗುವಷ್ಟು ಇಂಧನ ಹೊಂದಿರುವ ವ್ಯವಹಾರವನ್ನು ಕಳುಹಿಸುತ್ತಾನೆ, ಆದರೆ ಎರಡನೇ ಹಂತಕ್ಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ (ಅಂದರೆ ಹಣ ಹಿಂಪಡೆಯುವುದು ಆದರೆ ಶಿಲ್ಕು ಕಡಿಮೆಯಾಗಲು ಬಿಡದಿರುವುದು). ಒಪ್ಪಂದದ ರಚನಾಕಾರನು ಇಂತಹ ದಾಳಿಗಳಿಂದ ರಕ್ಷಿಸಿಕೊಳ್ಳುವ ಬಗ್ಗೆ ಚಿಂತಿಸಬೇಕಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಮಧ್ಯದಲ್ಲಿ ನಿಂತರೆ ಬದಲಾವಣೆಗಳು ಹಿಂತಿರುಗಿಸಲ್ಪಡುತ್ತವೆ. - ಒಂದು ಹಣಕಾಸು ಒಪ್ಪಂದವು ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಒಂಬತ್ತು ಮಾಲೀಕತ್ವದ ಡೇಟಾ ಫೀಡ್ಗಳ ಮಧ್ಯಮವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಒಬ್ಬ ಆಕ್ರಮಣಕಾರನು ಒಂದು ಡೇಟಾ ಫೀಡ್ ಅನ್ನು ವಶಪಡಿಸಿಕೊಳ್ಳುತ್ತಾನೆ, ಇದನ್ನು DAOಗಳ ವಿಭಾಗದಲ್ಲಿ ವಿವರಿಸಿದ ವೇರಿಯಬಲ್-ಅಡ್ರೆಸ್-ಕಾಲ್ ವಿಧಾನದ ಮೂಲಕ ಮಾರ್ಪಡಿಸಬಹುದಾಗಿದೆ, ಮತ್ತು ಅದನ್ನು ಅನಂತ ಲೂಪ್ ಓಡಲು ಪರಿವರ್ತಿಸುತ್ತಾನೆ, ಇದರಿಂದ ಹಣಕಾಸು ಒಪ್ಪಂದದಿಂದ ಹಣವನ್ನು ಪಡೆಯಲು ಯಾವುದೇ ಪ್ರಯತ್ನಗಳನ್ನು ಇಂಧನ ಖಾಲಿಯಾಗುವಂತೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಾನೆ. ಆದರೆ, ಹಣಕಾಸು ಒಪ್ಪಂದವು ಈ ಸಮಸ್ಯೆಯನ್ನು ತಡೆಯಲು ಸಂದೇಶಕ್ಕೆ ಇಂಧನ ಮಿತಿಯನ್ನು ಹೊಂದಿಸಬಹುದು.
ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣತೆಗೆ ಪರ್ಯಾಯವಾಗಿ ಟ್ಯೂರಿಂಗ್-ಅಸಂಪೂರ್ಣತೆ ಇದೆ, ಇಲ್ಲಿ JUMP
ಮತ್ತು JUMPI
ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಕಾಲ್ ಸ್ಟ್ಯಾಕ್ನಲ್ಲಿ ಪ್ರತಿ ಒಪ್ಪಂದದ ಒಂದೇ ಪ್ರತಿ ಇರಲು ಅನುಮತಿಸಲಾಗುತ್ತದೆ. ಈ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ, ವಿವರಿಸಿದ ಶುಲ್ಕ ವ್ಯವಸ್ಥೆ ಮತ್ತು ನಮ್ಮ ಪರಿಹಾರದ ಪರಿಣಾಮಕಾರಿತ್ವದ ಬಗ್ಗೆ ಅನಿಶ್ಚಿತತೆಗಳು ಅಗತ್ಯವಾಗಿರದೇ ಇರಬಹುದು, ಏಕೆಂದರೆ ಒಪ್ಪಂದವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ವೆಚ್ಚವು ಅದರ ಗಾತ್ರದಿಂದ ಮೇಲ್ಮಟ್ಟದಲ್ಲಿ ಬಂಧಿಸಲ್ಪಡುತ್ತದೆ. ಜೊತೆಗೆ, ಟ್ಯೂರಿಂಗ್-ಅಸಂಪೂರ್ಣತೆಯು ಅಷ್ಟೊಂದು ದೊಡ್ಡ ಮಿತಿಯಲ್ಲ; ನಾವು ಆಂತರಿಕವಾಗಿ ಯೋಚಿಸಿದ ಎಲ್ಲಾ ಒಪ್ಪಂದ ಉದಾಹರಣೆಗಳಲ್ಲಿ, ಇದುವರೆಗೆ ಕೇವಲ ಒಂದು ಮಾತ್ರ ಲೂಪ್ ಅಗತ್ಯವಿತ್ತು, ಮತ್ತು ಆ ಲೂಪ್ ಅನ್ನು ಸಹ ಒಂದು ಸಾಲಿನ ಕೋಡ್ನ 26 ಪುನರಾವರ್ತನೆಗಳನ್ನು ಮಾಡುವ ಮೂಲಕ ತೆಗೆದುಹಾಕಬಹುದಾಗಿತ್ತು. ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣತೆಯ ಗಂಭೀರ ಪರಿಣಾಮಗಳನ್ನು ಮತ್ತು ಸೀಮಿತ ಲಾಭವನ್ನು ನೋಡಿದಾಗ, ಏಕೆ ಕೇವಲ ಟ್ಯೂರಿಂಗ್-ಅಸಂಪೂರ್ಣ ಭಾಷೆಯನ್ನು ಹೊಂದಿರಬಾರದು? ವಾಸ್ತವದಲ್ಲಿ, ಆದರೆ, ಟ್ಯೂರಿಂಗ್-ಅಸಂಪೂರ್ಣತೆಯು ಸಮಸ್ಯೆಗೆ ಚೊಕ್ಕ ಪರಿಹಾರದಿಂದ ದೂರವಾಗಿದೆ. ಏಕೆಂದರೆ, ಈ ಕೆಳಗಿನ ಒಪ್ಪಂದಗಳನ್ನು ಪರಿಗಣಿಸಿ:
C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)
ಈಗ, A ಗೆ ಒಂದು ವ್ಯವಹಾರವನ್ನು ಕಳುಹಿಸಿ. ಹೀಗೆ, 51 ವ್ಯವಹಾರಗಳಲ್ಲಿ, ನಮ್ಮ ಬಳಿ 250 ಕಂಪ್ಯುಟೇಶನಲ್ ಹಂತಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಒಂದು ಒಪ್ಪಂದವಿದೆ. ಗಣಿಗಾರರು ಇಂತಹ ತರ್ಕ ಬಾಂಬ್ಗಳನ್ನು ಮುಂಚಿತವಾಗಿ ಪತ್ತೆಹಚ್ಚಲು ಪ್ರಯತ್ನಿಸಬಹುದು. ಪ್ರತಿ ಒಪ್ಪಂದದ ಜೊತೆಗೆ ಅದು ತೆಗೆದುಕೊಳ್ಳಬಹುದಾದ ಗರಿಷ್ಠ ಕಂಪ್ಯುಟೇಶನಲ್ ಹಂತಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಒಂದು ಮೌಲ್ಯವನ್ನು ನಿರ್ವಹಿಸುವ ಮೂಲಕ ಮತ್ತು ಇತರ ಒಪ್ಪಂದಗಳನ್ನು ಆವರ್ತಕವಾಗಿ ಕರೆಯುವ ಒಪ್ಪಂದಗಳಿಗಾಗಿ ಇದನ್ನು ಲೆಕ್ಕಹಾಕುವ ಮೂಲಕ ಇದನ್ನು ಮಾಡಬಹುದು. ಆದರೆ ಅದು ಗಣಿಗಾರರು ಇತರ ಒಪ್ಪಂದಗಳನ್ನು ರಚಿಸುವ ಒಪ್ಪಂದಗಳನ್ನು ನಿಷೇಧಿಸಬೇಕಾಗುತ್ತದೆ (ಏಕೆಂದರೆ ಮೇಲಿನ 26 ಒಪ್ಪಂದಗಳ ರಚನೆ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಸುಲಭವಾಗಿ ಒಂದೇ ಒಪ್ಪಂದದಲ್ಲಿ ಸುತ್ತಿಕೊಳ್ಳಬಹುದು). ಇನ್ನೊಂದು ಸಮಸ್ಯಾತ್ಮಕ ಅಂಶವೆಂದರೆ ಸಂದೇಶದ ವಿಳಾಸ ಕ್ಷೇತ್ರವು ಒಂದು ವೇರಿಯಬಲ್ ಆಗಿರುವುದರಿಂದ, ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಒಪ್ಪಂದವು ಯಾವ ಇತರ ಒಪ್ಪಂದಗಳನ್ನು ಮುಂಚಿತವಾಗಿ ಕರೆಯುತ್ತದೆ ಎಂದು ಹೇಳುವುದು ಸಾಧ್ಯವಾಗದಿರಬಹುದು. ಆದ್ದರಿಂದ, ಒಟ್ಟಾರೆಯಾಗಿ, ನಮ್ಮ ಬಳಿ ಒಂದು ಆಶ್ಚರ್ಯಕರ ತೀರ್ಮಾನವಿದೆ: ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣತೆಯು ಆಶ್ಚರ್ಯಕರವಾಗಿ ನಿರ್ವಹಿಸಲು ಸುಲಭವಾಗಿದೆ, ಮತ್ತು ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣತೆಯ ಕೊರತೆಯು ಸಮಾನವಾಗಿ ಆಶ್ಚರ್ಯಕರವಾಗಿ ನಿರ್ವಹಿಸಲು ಕಷ್ಟವಾಗಿದೆ, ನಿಖರವಾಗಿ ಅದೇ ನಿಯಂತ್ರಣಗಳು ಜಾರಿಯಲ್ಲಿಲ್ಲದಿದ್ದರೆ - ಆದರೆ ಆ ಸಂದರ್ಭದಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಏಕೆ ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣವಾಗಿರಬಾರದು?
ಕರೆನ್ಸಿ ಮತ್ತು ವಿತರಣೆ
ಎಥೆರಿಯಮ್ ನೆಟ್ವರ್ಕ್ ತನ್ನದೇ ಆದ ಅಂತರ್ನಿರ್ಮಿತ ಕರೆನ್ಸಿಯನ್ನು ಒಳಗೊಂಡಿದೆ, ಎಥೆರ್, ಇದು ಎರಡು ಉದ್ದೇಶಗಳನ್ನು ಹೊಂದಿದೆ: ವಿವಿಧ ರೀತಿಯ ಡಿಜಿಟಲ್ ಆಸ್ತಿಗಳ ನಡುವೆ ದಕ್ಷ ವಿನಿಮಯಕ್ಕೆ ಅನುವು ಮಾಡಿಕೊಡುವ ಪ್ರಾಥಮಿಕ ದ್ರವ್ಯತೆ ಪದರವನ್ನು ಒದಗಿಸುವುದು ಮತ್ತು ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿ, ವ್ಯವಹಾರ ಶುಲ್ಕಗಳನ್ನು ಪಾವತಿಸಲು ಒಂದು ಕಾರ್ಯವಿಧಾನವನ್ನು ಒದಗಿಸುವುದು. ಅನುಕೂಲಕ್ಕಾಗಿ ಮತ್ತು ಭವಿಷ್ಯದ ವಾದವನ್ನು ತಪ್ಪಿಸಲು (ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿ ಪ್ರಸ್ತುತ ನಡೆಯುತ್ತಿರುವ mBTC/uBTC/ಸತೋಷಿ ಚರ್ಚೆಯನ್ನು ನೋಡಿ), ಈ ಕೆಳಗಿನಂತೆ ಮೌಲ್ಯಗಳಿಗೆ ಮುಂಚಿತವಾಗಿಯೇ ಹೆಸರಿಡಲಾಗುವುದು:
- 1: wei
- 1012: szabo
- 015: finney
- 1018: ether
ಇದನ್ನು "ಡಾಲರ್ಗಳು" ಮತ್ತು "ಸೆಂಟ್ಗಳು" ಅಥವಾ "BTC" ಮತ್ತು "ಸತೋಷಿ" ಎಂಬ ಪರಿಕಲ್ಪನೆಯ ವಿಸ್ತೃತ ಆವೃತ್ತಿಯಾಗಿ ಪರಿಗಣಿಸಬೇಕು. ಸಮೀಪ ಭವಿಷ್ಯದಲ್ಲಿ, ನಾವು "ಎಥೆರ್" ಅನ್ನು ಸಾಮಾನ್ಯ ವ್ಯವಹಾರಗಳಿಗೆ, "ಫಿನ್ನಿ" ಅನ್ನು ಸೂಕ್ಷ್ಮ ವ್ಯವಹಾರಗಳಿಗೆ ಮತ್ತು "ಝಾಬೊ" ಮತ್ತು "ವೇ" ಅನ್ನು ಶುಲ್ಕಗಳ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಅನುಷ್ಠಾನದ ಬಗ್ಗೆ ತಾಂತ್ರಿಕ ಚರ್ಚೆಗಳಿಗೆ ಬಳಸಲಾಗುವುದು ಎಂದು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ; ಉಳಿದ ಮೌಲ್ಯಗಳು ನಂತರ ಉಪಯುಕ್ತವಾಗಬಹುದು ಮತ್ತು ಈ ಹಂತದಲ್ಲಿ ಕ್ಲೈಂಟ್ಗಳಲ್ಲಿ ಸೇರಿಸಬಾರದು.
ಹಣದ ಬಿಡುಗಡೆ ಮಾದರಿಯು ಈ ರೀತಿ ಇರಲಿದೆ:
- ಎಥೆರ್ ಅನ್ನು ಒಂದು ಕರೆನ್ಸಿ ಮಾರಾಟದಲ್ಲಿ ಪ್ರತಿ ಬಿಟ್ಕಾಯಿನ್ಗೆ 1000-2000 ಎಥೆರ್ ದರದಲ್ಲಿ ಬಿಡುಗಡೆ ಮಾಡಲಾಗುವುದು. ಈ ವಿಧಾನವು ಎಥೆರಿಯಮ್ ಸಂಸ್ಥೆಗೆ ಹಣ ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಅಭಿವೃದ್ಧಿಗೆ ಹಣ ಪಾವತಿಸಲು ಉದ್ದೇಶಿಸಲಾಗಿದೆ. ಈ ವಿಧಾನವನ್ನು ಮಾಸ್ಟರ್ಕಾಯಿನ್ ಮತ್ತು NXT ನಂತಹ ಇತರ ವೇದಿಕೆಗಳು ಯಶಸ್ವಿಯಾಗಿ ಬಳಸಿಕೊಂಡಿವೆ. ಮೊದಲು ಖರೀದಿಸುವವರಿಗೆ ಹೆಚ್ಚಿನ ರಿಯಾಯಿತಿಗಳ ಲಾಭ ದೊರೆಯುತ್ತದೆ. ಮಾರಾಟದಿಂದ ಬಂದ ಬಿಟ್ಕಾಯಿನ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಡೆವಲಪರ್ಗಳಿಗೆ ಸಂಬಳ ಮತ್ತು ಬೌಂಟಿಗಳನ್ನು ಪಾವತಿಸಲು ಬಳಸಲಾಗುವುದು ಮತ್ತು ಎಥೆರಿಯಮ್ ಹಾಗೂ ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ವಿವಿಧ ಲಾಭದಾಯಕ ಮತ್ತು ಲಾಭರಹಿತ ಯೋಜನೆಗಳಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡಲಾಗುವುದು.
- ಒಟ್ಟು ಮಾರಾಟವಾದ ಮೊತ್ತದ 0.099x ಪಟ್ಟು (60102216 ETH) ಅನ್ನು ಆರಂಭಿಕ ಕೊಡುಗೆದಾರರಿಗೆ ಪರಿಹಾರ ನೀಡಲು ಮತ್ತು ಜೆನೆಸಿಸ್ ಬ್ಲಾಕ್ಗಿಂತ ಮುಂಚೆ ETH-ನಾಮಿತ ವೆಚ್ಚಗಳನ್ನು ಪಾವತಿಸಲು ಸಂಸ್ಥೆಗೆ ನಿಗದಿಪಡಿಸಲಾಗುವುದು.
- ಒಟ್ಟು ಮಾರಾಟವಾದ ಮೊತ್ತದ 0.099x ಪಟ್ಟನ್ನು ದೀರ್ಘಾವಧಿ ಮೀಸಲಾಗಿ ಕಾಯ್ದಿರಿಸಲಾಗುವುದು.
- ಒಟ್ಟು ಮಾರಾಟವಾದ ಮೊತ್ತದ 0.26x ಪಟ್ಟನ್ನು ಅದರ ನಂತರ ಪ್ರತಿ ವರ್ಷ ಶಾಶ್ವತವಾಗಿ ಮೌಲ್ಯಮಾಪಕರಿಗೆ (ಮೈನರ್ಸ್) ನಿಗದಿಪಡಿಸಲಾಗುವುದು.
ಗುಂಪು | ಪ್ರಾರಂಭದಲ್ಲಿ | ಒಂದು ವರ್ಷದ ನಂತರ | 5 ವರ್ಷಗಳ ನಂತರ |
---|---|---|---|
ಕರೆನ್ಸಿ ಯುನಿಟ್ಗಳು | 1.198X | 1.458X | 1.458X |
ಖರೀದಿಗಳು | 83.5% | 68.6% | 40.0% |
ಮಾರಾಟಕ್ಕೆ ಮೊದಲು ಖರ್ಚು ಮಾಡಿದ ಮೀಸಲು | 8.26% | 6.79% | 3.96% |
ಮಾರಾಟದ ನಂತರ ಬಳಸಿದ ಮೀಸಲು | 8.26% | 6.79% | 3.96% |
ಗಣಿಗಾರರು | 0% | 17.8% | 52.0% |
ದೀರ್ಘಾವಧಿ ಪೂರೈಕೆ ಬೆಳವಣಿಗೆ ದರ (ಶೇಕಡಾವಾರು)
ರೇಖೀಯ ಕರೆನ್ಸಿ ಬಿಡುಗಡೆಯ ಹೊರತಾಗಿಯೂ, ಬಿಟ್ಕಾಯಿನ್ನಂತೆಯೇ, ಕಾಲಾಂತರದಲ್ಲಿ ಪೂರೈಕೆ ಬೆಳವಣಿಗೆ ದರವು ಶೂನ್ಯಕ್ಕೆ ಹತ್ತಿರವಾಗುತ್ತದೆ.
ಮೇಲಿನ ಮಾದರಿಯಲ್ಲಿನ ಎರಡು ಪ್ರಮುಖ ಆಯ್ಕೆಗಳೆಂದರೆ (1) ಒಂದು ದತ್ತಿ ನಿಧಿಯ ಅಸ್ತಿತ್ವ ಮತ್ತು ಗಾತ್ರ, ಮತ್ತು (2) ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿರುವಂತೆ ಮಿತಿಗೊಳಿಸಿದ ಪೂರೈಕೆಗೆ ಬದಲಾಗಿ ಶಾಶ್ವತವಾಗಿ ಬೆಳೆಯುವ ರೇಖೀಯ ಪೂರೈಕೆಯ ಅಸ್ತಿತ್ವ. ದತ್ತಿ ನಿಧಿಯ ಸಮರ್ಥನೆ ಹೀಗಿದೆ: ದತ್ತಿ ನಿಧಿ ಅಸ್ತಿತ್ವದಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ, ಮತ್ತು ಅದೇ ಹಣದುಬ್ಬರ ದರವನ್ನು ಒದಗಿಸಲು ರೇಖೀಯ ಬಿಡುಗಡೆಯನ್ನು 0.217x ಗೆ ಕಡಿಮೆ ಮಾಡಿದರೆ, ಆಗ ಎಥೆರ್ನ ಒಟ್ಟು ಪ್ರಮಾಣವು 16.5% ರಷ್ಟು ಕಡಿಮೆಯಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಘಟಕವು 19.8% ರಷ್ಟು ಹೆಚ್ಚು ಮೌಲ್ಯಯುತವಾಗಿರುತ್ತದೆ. ಹೀಗಾಗಿ, ಸಮತೋಲನದಲ್ಲಿ 19.8% ರಷ್ಟು ಹೆಚ್ಚು ಎಥೆರ್ ಅನ್ನು ಮಾರಾಟದಲ್ಲಿ ಖರೀದಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಘಟಕವು ಮತ್ತೆ ಮೊದಲಿನಂತೆಯೇ ಅಷ್ಟೇ ಮೌಲ್ಯಯುತವಾಗಿರುತ್ತದೆ. ಸಂಸ್ಥೆಯು ಸಹ 1.198x ಹೆಚ್ಚು ಬಿಟ್ಕಾಯಿನ್ ಹೊಂದಿರುತ್ತದೆ, ಇದನ್ನು ಎರಡು ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸಬಹುದು ಎಂದು ಪರಿಗಣಿಸಬಹುದು: ಮೂಲ BTC ಮತ್ತು ಹೆಚ್ಚುವರಿ 0.198x. ಆದ್ದರಿಂದ, ಈ ಪರಿಸ್ಥಿತಿಯು ದತ್ತಿ ನಿಧಿಗೆ ಸರಿಯಾಗಿ ಸಮಾನವಾಗಿದೆ, ಆದರೆ ಒಂದು ಮುಖ್ಯ ವ್ಯತ್ಯಾಸದೊಂದಿಗೆ: ಸಂಸ್ಥೆಯು ಕೇವಲ ಬಿಟ್ಕಾಯಿನ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಮತ್ತು ಹೀಗಾಗಿ ಎಥೆರ್ ಘಟಕದ ಮೌಲ್ಯವನ್ನು ಬೆಂಬಲಿಸಲು ಪ್ರೇರೇಪಿಸಲ್ಪಡುವುದಿಲ್ಲ.
ಶಾಶ್ವತ ರೇಖೀಯ ಪೂರೈಕೆ ಬೆಳವಣಿಗೆ ಮಾದರಿಯು ಕೆಲವರು ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿ ನೋಡುವ ಅತಿಯಾದ ಸಂಪತ್ತು ಕೇಂದ್ರೀಕರಣದ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಪ್ರಸ್ತುತ ಮತ್ತು ಭವಿಷ್ಯದ ಯುಗಗಳಲ್ಲಿ ವಾಸಿಸುವ ವ್ಯಕ್ತಿಗಳಿಗೆ ಕರೆನ್ಸಿ ಘಟಕಗಳನ್ನು ಸಂಪಾದಿಸಲು ನ್ಯಾಯಯುತ ಅವಕಾಶವನ್ನು ನೀಡುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, "ಪೂರೈಕೆ ಬೆಳವಣಿಗೆ ದರ"ವು ಶೇಕಡಾವಾರು ಕಾಲಾಂತರದಲ್ಲಿ ಶೂನ್ಯಕ್ಕೆ ಹತ್ತಿರವಾಗುವುದರಿಂದ ಎಥೆರ್ ಅನ್ನು ಪಡೆಯಲು ಮತ್ತು ಹೊಂದಿರಲು ಬಲವಾದ ಪ್ರೋತ್ಸಾಹವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನಾವು ಇದನ್ನೂ ಸಹ ಸಿದ್ಧಾಂತೀಕರಿಸುತ್ತೇವೆ: ಅಜಾಗರೂಕತೆ, ಮರಣ ಇತ್ಯಾದಿಗಳಿಂದಾಗಿ ಕಾಲಾಂತರದಲ್ಲಿ ನಾಣ್ಯಗಳು ಯಾವಾಗಲೂ ಕಳೆದುಹೋಗುತ್ತವೆ, ಮತ್ತು ನಾಣ್ಯ ನಷ್ಟವನ್ನು ಪ್ರತಿ ವರ್ಷ ಒಟ್ಟು ಪೂರೈಕೆಯ ಶೇಕಡಾವಾರಾಗಿ ಮಾದರಿಗೊಳಿಸಬಹುದು. ಆದ್ದರಿಂದ, ಸಂಚಲನೆಯಲ್ಲಿರುವ ಒಟ್ಟು ಕರೆನ್ಸಿ ಪೂರೈಕೆಯು ವಾಸ್ತವವಾಗಿ ಕೊನೆಗೆ ವಾರ್ಷಿಕ ಬಿಡುಗಡೆಯನ್ನು ನಷ್ಟ ದರದಿಂದ ಭಾಗಿಸಿದ ಮೌಲ್ಯಕ್ಕೆ ಸಮಾನವಾಗಿ ಸ್ಥಿರಗೊಳ್ಳುತ್ತದೆ (ಉದಾ. ಶೇಕಡಾ 1 ರ ನಷ್ಟ ದರದಲ್ಲಿ, ಒಮ್ಮೆ ಪೂರೈಕೆಯು 26X ತಲುಪಿದಾಗ, ಪ್ರತಿ ವರ್ಷ 0.26X ಅನ್ನು ಮೈನ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು 0.26X ಕಳೆದುಹೋಗುತ್ತದೆ, ಇದು ಸಮತೋಲನವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ).
ಭವಿಷ್ಯದಲ್ಲಿ, ಎಥೆರಿಯಮ್ ಭದ್ರತೆಗಾಗಿ ಪ್ರೂಫ್-ಆಫ್-ಸ್ಟೇಕ್ ಮಾದರಿಗೆ ಬದಲಾಗುವ ಸಾಧ್ಯತೆಯಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಇದು ಬಿಡುಗಡೆ ಅವಶ್ಯಕತೆಯನ್ನು ಪ್ರತಿ ವರ್ಷ ಸೊನ್ನೆ ಮತ್ತು 0.05X ನಡುವೆ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಭವಿಷ್ಯದಲ್ಲಿ ಎಥೆರಿಯಮ್ ಸಂಸ್ಥೆಯು ಹಣಕಾಸು ಕಳೆದುಕೊಂಡರೆ ಅಥವಾ ಯಾವುದೇ ಕಾರಣಕ್ಕೆ ಕಣ್ಮರೆಯಾದರೆ, ನಾವು ಒಂದು "ಸಾಮಾಜಿಕ ಒಪ್ಪಂದ"ವನ್ನು ತೆರೆದಿಡುತ್ತೇವೆ: ಯಾರಾದರೂ ಎಥೆರಿಯಮ್ನ ಭವಿಷ್ಯದ ಅಭ್ಯರ್ಥಿ ಆವೃತ್ತಿಯನ್ನು ರಚಿಸುವ ಹಕ್ಕನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಒಂದೇ ಒಂದು ಷರತ್ತಿನೊಂದಿಗೆ: ಈಥರ್ನ ಪ್ರಮಾಣವು ಗರಿಷ್ಠ 60102216 * (1.198 + 0.26 * n)
ಗೆ ಸಮನಾಗಿರಬೇಕು, ಇಲ್ಲಿ n
ಎಂದರೆ ಜೆನೆಸಿಸ್ ಬ್ಲಾಕ್ನ ನಂತರದ ವರ್ಷಗಳ ಸಂಖ್ಯೆ. ರಚನಾಕಾರರು ಪ್ರೂಫ್-ಆಫ್-ಸ್ಟೇಕ್ ಚಾಲಿತ ಪೂರೈಕೆ ವಿಸ್ತರಣೆ ಮತ್ತು ಗರಿಷ್ಠ ಅನುಮತಿಸಬಹುದಾದ ಪೂರೈಕೆ ವಿಸ್ತರಣೆ ನಡುವಿನ ವ್ಯತ್ಯಾಸದ ಕೆಲವು ಅಥವಾ ಎಲ್ಲವನ್ನು ಅಭಿವೃದ್ಧಿಗೆ ಹಣ ಪಾವತಿಸಲು ಜನಸಮೂಹ-ಮಾರಾಟ ಮಾಡಲು ಅಥವಾ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ನಿಯೋಜಿಸಲು ಮುಕ್ತರಾಗಿದ್ದಾರೆ. ಸಾಮಾಜಿಕ ಒಪ್ಪಂದಕ್ಕೆ ಅನುಗುಣವಾಗಿಲ್ಲದ ಅಭ್ಯರ್ಥಿ ನವೀಕರಣಗಳನ್ನು ನ್ಯಾಯಸಮ್ಮತವಾಗಿ ಅನುಸರಣೆಯ ಆವೃತ್ತಿಗಳಾಗಿ ಶಾಖೆ ಮಾಡಬಹುದು.
ಗಣಿಗಾರಿಕೆ ಕೇಂದ್ರೀಕರಣ
ಬಿಟ್ಕಾಯಿನ್ ಗಣಿಗಾರಿಕೆ ಅಲ್ಗಾರಿದಮ್ ಹೀಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ಗಣಿಗಾರರು ಬ್ಲಾಕ್ ಹೆಡರ್ನ ಸ್ವಲ್ಪ ಮಾರ್ಪಡಿಸಿದ ಆವೃತ್ತಿಗಳ ಮೇಲೆ SHA256 ಅನ್ನು ಮಿಲಿಯನ್ ಬಾರಿ ಮತ್ತೆ ಮತ್ತೆ ಕಂಪ್ಯೂಟ್ ಮಾಡುತ್ತಾರೆ, ಕೊನೆಗೆ ಒಂದು ನೋಡ್ ಗುರಿಗಿಂತ ಕಡಿಮೆ ಹ್ಯಾಶ್ ಹೊಂದಿರುವ ಆವೃತ್ತಿಯನ್ನು ಕಂಡುಹಿಡಿಯುವವರೆಗೆ (ಪ್ರಸ್ತುತ ಸುಮಾರು 2192). ಆದಾಗ್ಯೂ, ಈ ಗಣಿಗಾರಿಕೆ ಅಲ್ಗಾರಿದಮ್ ಎರಡು ರೀತಿಯ ಕೇಂದ್ರೀಕರಣಕ್ಕೆ ದುರ್ಬಲವಾಗಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ಗಣಿಗಾರಿಕೆ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯು ASIC ಗಳಿಂದ (ಅಪ್ಲಿಕೇಶನ್-ನಿರ್ದಿಷ್ಟ ಸಮಗ್ರ ಸರ್ಕ್ಯೂಟ್ಗಳು) ಆವರಿಸಲ್ಪಟ್ಟಿದೆ. ಇವು ಬಿಟ್ಕಾಯಿನ್ ಗಣಿಗಾರಿಕೆಯ ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಕ್ಕಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲ್ಪಟ್ಟ ಕಂಪ್ಯೂಟರ್ ಚಿಪ್ಗಳಾಗಿದ್ದು, ಸಾವಿರಾರು ಪಟ್ಟು ಹೆಚ್ಚು ದಕ್ಷವಾಗಿವೆ. ಇದರರ್ಥ ಬಿಟ್ಕಾಯಿನ್ ಗಣಿಗಾರಿಕೆ ಇನ್ನು ಮುಂದೆ ಅತ್ಯಂತ ವಿಕೇಂದ್ರೀಕೃತ ಮತ್ತು ಸಮತಾವಾದಿ ಉದ್ಯಮವಲ್ಲ; ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಭಾಗವಹಿಸಲು ಮಿಲಿಯನ್ಗಟ್ಟಲೆ ಡಾಲರ್ಗಳ ಬಂಡವಾಳ ಅಗತ್ಯವಿದೆ. ಎರಡನೆಯದಾಗಿ, ಹೆಚ್ಚಿನ ಬಿಟ್ಕಾಯಿನ್ ಗಣಿಗಾರರು ವಾಸ್ತವವಾಗಿ ಸ್ಥಳೀಯವಾಗಿ ಬ್ಲಾಕ್ ಮೌಲ್ಯಮಾಪನವನ್ನು ನಿರ್ವಹಿಸುವುದಿಲ್ಲ; ಬದಲಾಗಿ, ಅವರು ಬ್ಲಾಕ್ ಹೆಡರ್ಗಳನ್ನು ಒದಗಿಸಲು ಕೇಂದ್ರೀಕೃತ ಗಣಿಗಾರಿಕೆಯ ಪೂಲ್ ಅನ್ನು ಅವಲಂಬಿಸುತ್ತಾರೆ. ಈ ಸಮಸ್ಯೆಯು ಹೆಚ್ಚು ಕೆಟ್ಟದಾಗಿದೆ ಎಂದು ವಾದಿಸಬಹುದು: ಈ ಬರಹದ ಸಮಯದಲ್ಲಿ, ಮೇಲಿನ ಮೂರು ಮೈನಿಂಗ್ ಪೂಲ್ಗಳು ಪರೋಕ್ಷವಾಗಿ ಬಿಟ್ಕಾಯಿನ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಸುಮಾರು 50% ರಷ್ಟು ಪ್ರಕ್ರಿಯೆ ಶಕ್ತಿಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ. ಆದರೆ ಇದನ್ನು ಗಣಿಗಾರರು ಒಂದು ಪೂಲ್ ಅಥವಾ ಒಕ್ಕೂಟವು 51% ರಷ್ಟು ದಾಳಿ ಪ್ರಯತ್ನಿಸಿದರೆ ಇತರ ಗಣಿಗಾರಿಕೆ ಪೂಲ್ಗಳಿಗೆ ಬದಲಾಯಿಸಬಹುದು ಎಂಬ ಅಂಶದಿಂದ ತಗ್ಗಿಸಲಾಗಿದೆ.
ಎಥೆರಿಯಮ್ನಲ್ಲಿ ಪ್ರಸ್ತುತ ಉದ್ದೇಶವು ಗಣಿಗಾರರು ಸ್ಥಿತಿಯಿಂದ ಯಾದೃಚ್ಛಿಕ ಡೇಟಾವನ್ನು ಪಡೆಯಬೇಕಾಗುವ, ಬ್ಲಾಕ್ಚೈನ್ನಲ್ಲಿನ ಕೊನೆಯ N ಬ್ಲಾಕ್ಗಳಿಂದ ಯಾದೃಚ್ಛಿಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ ಕೆಲವು ವಹಿವಾಟುಗಳನ್ನು ಕಂಪ್ಯೂಟ್ ಮಾಡಬೇಕಾಗುವ ಮತ್ತು ಫಲಿತಾಂಶದ ಹ್ಯಾಶ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕಾಗುವ ಗಣಿಗಾರಿಕೆ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಬಳಸುವುದಾಗಿದೆ. ಇದು ಎರಡು ಮುಖ್ಯ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ: ಮೊದಲನೆಯದಾಗಿ, ಎಥೆರಿಯಮ್ ಒಪ್ಪಂದಗಳು ಯಾವುದೇ ರೀತಿಯ ಕಂಪ್ಯೂಟೇಶನ್ ಅನ್ನು ಒಳಗೊಳ್ಳಬಹುದು, ಆದ್ದರಿಂದ ಎಥೆರಿಯಮ್ ASIC ಅನ್ನು ಸಾಮಾನ್ಯ ಕಂಪ್ಯೂಟೇಶನ್ಗಾಗಿ ASIC ಎಂದು ಪರಿಗಣಿಸಬಹುದು - ಅಂದರೆ ಉತ್ತಮ CPU. ಎರಡನೆಯದಾಗಿ, ಗಣಿಗಾರಿಕೆಗೆ ಸಂಪೂರ್ಣ ಬ್ಲಾಕ್ಚೈನ್ಗೆ ಪ್ರವೇಶದ ಅಗತ್ಯವಿದೆ, ಇದು ಗಣಿಗಾರರು ಸಂಪೂರ್ಣ ಬ್ಲಾಕ್ಚೈನ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಕನಿಷ್ಠ ಪಕ್ಷ ಪ್ರತಿ ವಹಿವಾಟನ್ನು ಪರಿಶೀಲಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಒತ್ತಾಯಿಸುತ್ತದೆ. ಇದು ಕೇಂದ್ರೀಕೃತ ಗಣಿಗಾರಿಕೆ ಪೂಲ್ಗಳ ಅಗತ್ಯವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ; ಗಣಿಗಾರಿಕೆ ಪೂಲ್ಗಳು ಇನ್ನೂ ಬಹುಮಾನ ವಿತರಣೆಯ ಯಾದೃಚ್ಛಿಕತೆಯನ್ನು ಸಮತೋಲನಗೊಳಿಸುವ ನ್ಯಾಯಸಮ್ಮತ ಪಾತ್ರವನ್ನು ನಿರ್ವಹಿಸಬಹುದಾದರೂ, ಈ ಕಾರ್ಯವನ್ನು ಕೇಂದ್ರೀಕೃತ ನಿಯಂತ್ರಣವಿಲ್ಲದ ಪೀರ್-ಟು-ಪೀರ್ ಪೂಲ್ಗಳಿಂದ ಸಮಾನವಾಗಿ ನಿರ್ವಹಿಸಬಹುದು.
ಈ ಮಾದರಿಯನ್ನು ಇನ್ನೂ ಪರೀಕ್ಷಿಸಲಾಗಿಲ್ಲ, ಮತ್ತು ಒಪ್ಪಂದ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಗಣಿಗಾರಿಕೆ ಅಲ್ಗಾರಿದಮ್ ಆಗಿ ಬಳಸುವಾಗ ಕೆಲವು ಚತುರ ಉನ್ನತೀಕರಣಗಳನ್ನು ತಪ್ಪಿಸುವಲ್ಲಿ ಕಷ್ಟಗಳಿರಬಹುದು. ಆದಾಗ್ಯೂ, ಈ ಅಲ್ಗಾರಿದಮ್ನ ಒಂದು ಗಮನಾರ್ಹವಾಗಿ ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ ಅದು ಯಾರಿಗಾದರೂ "ಬಾವಿಯನ್ನು ವಿಷಯುಕ್ತಗೊಳಿಸಲು" ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದನ್ನು ನಿರ್ದಿಷ್ಟ ASIC ಗಳನ್ನು ತಡೆಯಲು ವಿಶೇಷವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಒಪ್ಪಂದಗಳನ್ನು ಬ್ಲಾಕ್ಚೈನ್ಗೆ ಪರಿಚಯಿಸುವ ಮೂಲಕ ಮಾಡಬಹುದು. ASIC ತಯಾರಕರು ಒಬ್ಬರನ್ನೊಬ್ಬರು ಆಕ್ರಮಿಸಲು ಇಂತಹ ತಂತ್ರವನ್ನು ಬಳಸಲು ಆರ್ಥಿಕ ಪ್ರೋತ್ಸಾಹಗಳಿವೆ. ಹೀಗಾಗಿ, ನಾವು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವ ಪರಿಹಾರವು ಕೇವಲ ತಾಂತ್ರಿಕ ಪರಿಹಾರವಾಗಿರದೆ, ಅಂತಿಮವಾಗಿ ಹೊಂದಾಣಿಕೆಯ ಆರ್ಥಿಕ ಮಾನವ ಪರಿಹಾರವಾಗಿದೆ.
Scalability
ಎಥೆರಿಯಮ್ ಬಗ್ಗೆ ಒಂದು ಸಾಮಾನ್ಯ ಕಾಳಜಿಯೆಂದರೆ ಸ್ಕೇಲೇಬಿಲಿಟಿಯ ಸಮಸ್ಯೆ. ಬಿಟ್ಕಾಯಿನ್ನಂತೆಯೇ, ಎಥೆರಿಯಮ್ ಕೂಡ ಪ್ರತಿ ವಹಿವಾಟನ್ನು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿನ ಪ್ರತಿ ನೋಡ್ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾದ ದೋಷದಿಂದ ಬಳಲುತ್ತದೆ. ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿ, ಪ್ರಸ್ತುತ ಬ್ಲಾಕ್ಚೈನ್ನ ಗಾತ್ರವು ಸುಮಾರು 15 GB ಇದ್ದು, ಪ್ರತಿ ಗಂಟೆಗೆ ಸುಮಾರು 1 MB ಬೆಳೆಯುತ್ತಿದೆ. ಬಿಟ್ಕಾಯಿನ್ ನೆಟ್ವರ್ಕ್ ವೀಸಾದ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 2000 ವಹಿವಾಟುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾದರೆ, ಅದು ಪ್ರತಿ ಮೂರು ಸೆಕೆಂಡುಗಳಿಗೆ 1 MB ನಷ್ಟು ಬೆಳೆಯುತ್ತದೆ (ಪ್ರತಿ ಗಂಟೆಗೆ 1 GB, ಪ್ರತಿ ವರ್ಷಕ್ಕೆ 8 TB). ಎಥೆರಿಯಮ್ ಇದೇ ರೀತಿಯ ಬೆಳವಣಿಗೆ ಮಾದರಿಯನ್ನು ಅನುಭವಿಸುವ ಸಾಧ್ಯತೆಯಿದೆ. ಬಿಟ್ಕಾಯಿನ್ನಲ್ಲಿ ಕೇವಲ ಕರೆನ್ಸಿ ಮಾತ್ರ ಇರುವಂತೆ ಅಲ್ಲದೆ, ಎಥೆರಿಯಮ್ ಬ್ಲಾಕ್ಚೈನ್ನ ಮೇಲೆ ಅನೇಕ ಅಪ್ಲಿಕೇಶನ್ಗಳಿರುವ ಕಾರಣ ಇದು ಹದಗೆಡುತ್ತದೆ. ಆದರೆ ಎಥೆರಿಯಮ್ ಪೂರ್ಣ ನೋಡ್ಗಳು ಸಂಪೂರ್ಣ ಬ್ಲಾಕ್ಚೈನ್ ಇತಿಹಾಸದ ಬದಲು ಕೇವಲ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಬೇಕಾಗಿರುವುದರಿಂದ ಇದನ್ನು ಸುಧಾರಿಸಲಾಗುತ್ತದೆ.
ಇಂತಹ ದೊಡ್ಡ ಬ್ಲಾಕ್ಚೈನ್ ಗಾತ್ರದೊಂದಿಗಿನ ಸಮಸ್ಯೆಯೆಂದರೆ ಕೇಂದ್ರೀಕರಣದ ಅಪಾಯ. ಬ್ಲಾಕ್ಚೈನ್ ಗಾತ್ರವು, ಉದಾಹರಣೆಗೆ, 100 TB ಗೆ ಹೆಚ್ಚಾದರೆ, ಸಂಭಾವ್ಯ ದೃಶ್ಯವೆಂದರೆ ಕೇವಲ ಕೆಲವೇ ಸಂಖ್ಯೆಯ ದೊಡ್ಡ ವ್ಯಾಪಾರಗಳು ಪೂರ್ಣ ನೋಡ್ಗಳನ್ನು ಚಲಾಯಿಸುತ್ತವೆ, ಎಲ್ಲಾ ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರು ಹಗುರ SPV ನೋಡ್ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ. ಇಂತಹ ಸಂದರ್ಭದಲ್ಲಿ, ಪೂರ್ಣ ನೋಡ್ಗಳು ಒಟ್ಟುಗೂಡಿ ಲಾಭದಾಯಕ ರೀತಿಯಲ್ಲಿ ವಂಚಿಸಲು ಒಪ್ಪಿಕೊಳ್ಳಬಹುದು (ಉದಾ. ಬ್ಲಾಕ್ ಬಹುಮಾನವನ್ನು ಬದಲಾಯಿಸುವುದು, ತಮಗೆ ಬಿಟ್ಕಾಯಿನ್ ನೀಡುವುದು) ಎಂಬ ಸಂಭಾವ್ಯ ಕಾಳಜಿ ಉದ್ಭವಿಸುತ್ತದೆ. ಹಗುರ ನೋಡ್ಗಳು ಇದನ್ನು ತಕ್ಷಣವೇ ಪತ್ತೆಹಚ್ಚುವ ಮಾರ್ಗವಿರುವುದಿಲ್ಲ. ಅವಶ್ಯವಾಗಿ, ಕನಿಷ್ಠ ಒಂದು ಪ್ರಾಮಾಣಿಕ ಪೂರ್ಣ ನೋಡ್ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಾಧ್ಯತೆಯಿದೆ, ಮತ್ತು ಕೆಲವು ಗಂಟೆಗಳ ನಂತರ ವಂಚನೆಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯು ರೆಡ್ಡಿಟ್ನಂತಹ ಮಾಧ್ಯಮಗಳ ಮೂಲಕ ಹರಡುತ್ತದೆ. ಆದರೆ ಆ ಹಂತದಲ್ಲಿ ಅದು ತುಂಬಾ ತಡವಾಗಿರುತ್ತದೆ: ಕೊಟ್ಟ ಬ್ಲಾಕ್ಗಳನ್ನು ಕಪ್ಪುಪಟ್ಟಿಗೆ ಸೇರಿಸಲು ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರು ಪ್ರಯತ್ನವನ್ನು ಸಂಘಟಿಸಬೇಕಾಗುತ್ತದೆ. ಇದು 51% ರಷ್ಟು ದಾಳಿಯನ್ನು ಯಶಸ್ವಿಯಾಗಿ ನಡೆಸುವಂತಹ ಪ್ರಮಾಣದ ಭಾರೀ ಮತ್ತು ಸಂಭವನೀಯವಾಗಿ ಅಸಾಧ್ಯವಾದ ಸಮನ್ವಯ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಬಿಟ್ಕಾಯಿನ್ನ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಪ್ರಸ್ತುತ ಒಂದು ಸಮಸ್ಯೆಯಾಗಿದೆ, ಆದರೆ ಪೀಟರ್ ಟಾಡ್(opens in a new tab) ಸೂಚಿಸಿದ ಬ್ಲಾಕ್ಚೈನ್ ಮಾರ್ಪಾಡು ಈ ಸಮಸ್ಯೆಯನ್ನು ನಿವಾರಿಸುತ್ತದೆ.
ಹ್ರಸ್ವಾವಧಿಯಲ್ಲಿ, ಎಥೆರಿಯಮ್ ಈ ಸಮಸ್ಯೆಯನ್ನು ನಿಭಾಯಿಸಲು ಎರಡು ಹೆಚ್ಚುವರಿ ತಂತ್ರಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ಬ್ಲಾಕ್ಚೈನ್ ಆಧಾರಿತ ಗಣಿಗಾರಿಕೆ ಅಲ್ಗಾರಿದಮ್ಗಳ ಕಾರಣದಿಂದಾಗಿ, ಕನಿಷ್ಠ ಪ್ರತಿ ಗಣಿಗಾರ ಪೂರ್ಣ ನೋಡ್ ಆಗಿರಲು ಒತ್ತಾಯಿಸಲ್ಪಡುತ್ತಾರೆ, ಇದು ಪೂರ್ಣ ನೋಡ್ಗಳ ಸಂಖ್ಯೆಯ ಕನಿಷ್ಠ ಮಿತಿಯನ್ನು ರಚಿಸುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ ಮತ್ತು ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿ, ಪ್ರತಿ ವಹಿವಾಟನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ನಂತರ ನಾವು ಬ್ಲಾಕ್ಚೈನ್ನಲ್ಲಿ ಮಧ್ಯಂತರ ಸ್ಥಿತಿ ಮರದ ಮೂಲವನ್ನು ಸೇರಿಸುತ್ತೇವೆ. ಬ್ಲಾಕ್ ಮೌಲ್ಯಮಾಪನವು ಕೇಂದ್ರೀಕೃತವಾಗಿದ್ದರೂ, ಒಂದು ಪ್ರಾಮಾಣಿಕ ಪರಿಶೀಲನಾ ನೋಡ್ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವವರೆಗೆ, ಕೇಂದ್ರೀಕರಣ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಶೀಲನಾ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಸುತ್ತುಹಾಕಬಹುದು. ಒಬ್ಬ ಗಣಿಗಾರ ಅಮಾನ್ಯ ಬ್ಲಾಕ್ ಅನ್ನು ಪ್ರಕಟಿಸಿದರೆ, ಆ ಬ್ಲಾಕ್ ಕೆಟ್ಟದಾಗಿ ರೂಪಿಸಲ್ಪಟ್ಟಿರಬೇಕು, ಅಥವಾ ಸ್ಥಿತಿ S[n]
ತಪ್ಪಾಗಿರಬೇಕು. S[0
] ಸರಿಯಾಗಿದೆ ಎಂದು ತಿಳಿದಿರುವುದರಿಂದ, S[i-1]
ಸರಿಯಾಗಿರುವಾಗ ಮೊದಲ ಸ್ಥಿತಿ S[i]
ತಪ್ಪಾಗಿರಬೇಕು. ಪರಿಶೀಲನಾ ನೋಡ್ ಸೂಚ್ಯಂಕ i
ಯನ್ನು ಒದಗಿಸುತ್ತದೆ, ಜೊತೆಗೆ APPLY(S[i-1],TX[i]) -> S[i]
ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅಗತ್ಯವಿರುವ ಪೆಟ್ರೀಷಿಯಾ ಮರದ ನೋಡ್ಗಳ ಉಪಗುಂಪನ್ನು ಒಳಗೊಂಡ "ಅಮಾನ್ಯತೆಯ ಪುರಾವೆ"ಯನ್ನು ನೀಡುತ್ತದೆ. ನೋಡ್ಗಳು ಆ ನೋಡ್ಗಳನ್ನು ಬಳಸಿ ಕಂಪ್ಯೂಟೇಶನ್ನ ಆ ಭಾಗವನ್ನು ಚಲಾಯಿಸಲು ಮತ್ತು ರಚಿಸಲಾದ S[i]
ಒದಗಿಸಲಾದ S[i]
ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ನೋಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಇನ್ನೊಂದು, ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ದಾಳಿಯು ದುರುದ್ದೇಶಪೂರಿತ ಗಣಿಗಾರರು ಅಪೂರ್ಣ ಬ್ಲಾಕ್ಗಳನ್ನು ಪ್ರಕಟಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಬ್ಲಾಕ್ಗಳು ಮಾನ್ಯವೇ ಅಲ್ಲವೇ ಎಂದು ನಿರ್ಧರಿಸಲು ಪೂರ್ಣ ಮಾಹಿತಿ ಇರುವುದಿಲ್ಲ. ಇದಕ್ಕೆ ಪರಿಹಾರವೆಂದರೆ ಸವಾಲು-ಪ್ರತಿಕ್ರಿಯೆ ಪ್ರೋಟೋಕಾಲ್: ಪರಿಶೀಲನಾ ನೋಡ್ಗಳು ಗುರಿ ವಹಿವಾಟು ಸೂಚ್ಯಂಕಗಳ ರೂಪದಲ್ಲಿ "ಸವಾಲುಗಳನ್ನು" ನೀಡುತ್ತವೆ, ಮತ್ತು ಒಂದು ನೋಡ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಹಗುರ ನೋಡ್ ಆ ಬ್ಲಾಕ್ ಅನ್ನು ಅನಪೇಕ್ಷಿತವೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ, ಇನ್ನೊಂದು ನೋಡ್, ಅದು ಗಣಿಗಾರ ಅಥವಾ ಇನ್ನೊಂದು ಪರಿಶೀಲಕ, ಮಾನ್ಯತೆಯ ಪುರಾವೆಯಾಗಿ ಪೆಟ್ರೀಷಿಯಾ ನೋಡ್ಗಳ ಉಪಗುಂಪನ್ನು ಒದಗಿಸುವವರೆಗೆ.
ಸಮಾರೋಪ
ಎಥೆರಿಯಮ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಮೂಲತಃ ಕ್ರಿಪ್ಟೋಕರೆನ್ಸಿಯ ಉನ್ನತೀಕೃತ ಆವೃತ್ತಿಯಾಗಿ ಕಲ್ಪಿಸಲಾಗಿತ್ತು. ಇದು ಬ್ಲಾಕ್ಚೈನ್ನಲ್ಲಿ ಎಸ್ಕ್ರೋ, ಹಿಂಪಡೆಯುವಿಕೆ ಮಿತಿಗಳು, ಹಣಕಾಸು ಒಪ್ಪಂದಗಳು, ಜೂಜಿನ ಮಾರುಕಟ್ಟೆಗಳು ಮುಂತಾದ ಸುಧಾರಿತ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಅತ್ಯಂತ ಸಾಮಾನ್ಯೀಕೃತ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯ ಮೂಲಕ ಒದಗಿಸುತ್ತದೆ. ಎಥೆರಿಯಮ್ ಪ್ರೋಟೋಕಾಲ್ ನೇರವಾಗಿ ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು "ಬೆಂಬಲಿಸುವುದಿಲ್ಲ", ಆದರೆ ಟ್ಯೂರಿಂಗ್-ಸಂಪೂರ್ಣ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯ ಅಸ್ತಿತ್ವವು ಯಾವುದೇ ವಹಿವಾಟು ಪ್ರಕಾರ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ಗಾಗಿ ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಯಾವುದೇ ಒಪ್ಪಂದಗಳನ್ನು ರಚಿಸಬಹುದು ಎಂದು ಅರ್ಥ. ಆದಾಗ್ಯೂ, ಎಥೆರಿಯಮ್ ಬಗ್ಗೆ ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕವಾದದ್ದು ಎಂದರೆ ಎಥೆರಿಯಮ್ ಪ್ರೋಟೋಕಾಲ್ ಕೇವಲ ಕರೆನ್ಸಿಯನ್ನು ಮೀರಿ ಬಹಳ ದೂರ ಸಾಗುತ್ತದೆ. ವಿಕೇಂದ್ರೀಕೃತ ಫೈಲ್ ಸಂಗ್ರಹಣೆ, ವಿಕೇಂದ್ರೀಕೃತ ಕಂಪ್ಯುಟೇಶನ್ ಮತ್ತು ವಿಕೇಂದ್ರೀಕೃತ ಮುನ್ಸೂಚನೆ ಮಾರುಕಟ್ಟೆಗಳ ಸುತ್ತಲಿನ ಪ್ರೋಟೋಕಾಲ್ಗಳು, ಇನ್ನೂ ಹಲವಾರು ಇಂತಹ ಪರಿಕಲ್ಪನೆಗಳೊಂದಿಗೆ, ಗಣಕೀಯ ಉದ್ಯಮದ ದಕ್ಷತೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿವೆ, ಮತ್ತು ಮೊದಲ ಬಾರಿಗೆ ಆರ್ಥಿಕ ಪದರವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಇತರ ಸಮಾನರಿಂದ ಸಮಾನ ಪ್ರೋಟೋಕಾಲ್ಗಳಿಗೆ ದೊಡ್ಡ ಉತ್ತೇಜನವನ್ನು ನೀಡುತ್ತವೆ. ಕೊನೆಯದಾಗಿ, ಹಣಕ್ಕೆ ಸಂಬಂಧವೇ ಇಲ್ಲದ ಗಣನೀಯ ಸಂಖ್ಯೆಯ ಅಪ್ಲಿಕೇಶನ್ಗಳೂ ಇವೆ.
ಎಥೆರಿಯಮ್ ಪ್ರೋಟೋಕಾಲ್ ಅನುಷ್ಠಾನಗೊಳಿಸಿದಂತೆ ಯಾದೃಚ್ಛಿಕ ಸ್ಥಿತಿ ಪರಿವರ್ತನೆ ಕಾರ್ಯದ ಪರಿಕಲ್ಪನೆಯು ಅನನ್ಯ ಸಾಮರ್ಥ್ಯದ ವೇದಿಕೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ; ಡೇಟಾ ಸಂಗ್ರಹಣೆ, ಜೂಜು ಅಥವಾ ಹಣಕಾಸಿನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್ಗಳ ಶ್ರೇಣಿಗಾಗಿ ಉದ್ದೇಶಿತವಾದ ಮುಚ್ಚಿದ-ಕೊನೆಯ, ಏಕ-ಉದ್ದೇಶದ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿರುವ ಬದಲು, ಎಥೆರಿಯಮ್ ವಿನ್ಯಾಸದಿಂದಲೇ ಮುಕ್ತ-ಕೊನೆಯದಾಗಿದೆ, ಮತ್ತು ಮುಂಬರುವ ವರ್ಷಗಳಲ್ಲಿ ಹಣಕಾಸು ಮತ್ತು ಹಣಕಾಸೇತರ ಎರಡೂ ಪ್ರೋಟೋಕಾಲ್ಗಳ ಬಹಳ ದೊಡ್ಡ ಸಂಖ್ಯೆಗೆ ಅಡಿಪಾಯದ ಪದರವಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸಲು ಇದು ಅತ್ಯಂತ ಸೂಕ್ತವಾಗಿದೆ ಎಂದು ನಾವು ನಂಬುತ್ತೇವೆ.
ಟಿಪ್ಪಣಿಗಳು ಮತ್ತು ಮುಂದಿನ ಓದುವಿಕೆ
ಟಿಪ್ಪಣಿಗಳು
- ಪರಿಣತ ಓದುಗರು ವಾಸ್ತವವಾಗಿ ಬಿಟ್ಕಾಯಿನ್ ವಿಳಾಸವು ದೀರ್ಘವೃತ್ತ ವಕ್ರರೇಖೆಯ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯ ಹ್ಯಾಶ್ ಆಗಿದೆ, ಸಾರ್ವಜನಿಕ ಕೀಲಿಯೇ ಅಲ್ಲ ಎಂದು ಗಮನಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಪಬ್ಕೀ ಹ್ಯಾಶ್ ಅನ್ನು ಸಾರ್ವಜನಿಕ ಕೀಲಿಯೆಂದೇ ಉಲ್ಲೇಖಿಸುವುದು ವಾಸ್ತವವಾಗಿ ಸಂಪೂರ್ಣ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಪದಾವಳಿಯಾಗಿದೆ. ಇದಕ್ಕೆ ಕಾರಣವೇನೆಂದರೆ ಬಿಟ್ಕಾಯಿನ್ನ ಕ್ರಿಪ್ಟೋಗ್ರಫಿಯನ್ನು ಕಸ್ಟಮ್ ಡಿಜಿಟಲ್ ಸಹಿ ಅಲ್ಗಾರಿದಮ್ ಎಂದು ಪರಿಗಣಿಸಬಹುದು, ಇಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯು ECC ಪಬ್ಕೀಯ ಹ್ಯಾಶ್ನಿಂದ ಕೂಡಿರುತ್ತದೆ, ಸಹಿಯು ECC ಪಬ್ಕೀ ಮತ್ತು ECC ಸಹಿಯನ್ನು ಜೋಡಿಸಿದ್ದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಮತ್ತು ಪರಿಶೀಲನೆ ಅಲ್ಗಾರಿದಮ್ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯಾಗಿ ಒದಗಿಸಲಾದ ECC ಪಬ್ಕೀ ಹ್ಯಾಶ್ನ ವಿರುದ್ಧ ಸಹಿಯಲ್ಲಿನ ECC ಪಬ್ಕೀಯನ್ನು ಪರಿಶೀಲಿಸುವುದು ಮತ್ತು ನಂತರ ECC ಪಬ್ಕೀಗೆ ವಿರುದ್ಧವಾಗಿ ECC ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.
- ತಾಂತ್ರಿಕವಾಗಿ, ಹಿಂದಿನ 11 ಬ್ಲಾಕ್ಗಳ ಸರಾಸರಿ.
- ಆಂತರಿಕವಾಗಿ, 2 ಮತ್ತು "CHARLIE" ಎರಡೂ ಸಂಖ್ಯೆಗಳು [fn3] (#notes) ಆಗಿದ್ದು, ಎರಡನೆಯದು ಬಿಗ್-ಎಂಡಿಯನ್ ಬೇಸ್ 256 ಪ್ರಾತಿನಿಧ್ಯದಲ್ಲಿದೆ. ಸಂಖ್ಯೆಗಳು ಕನಿಷ್ಠ 0 ಮತ್ತು ಗರಿಷ್ಠ 2256-1 ಆಗಿರಬಹುದು.
Further Reading
- ಆಂತರಿಕ ಮೌಲ್ಯ(opens in a new tab)
- ಸ್ಮಾರ್ಟ್ ಆಸ್ತಿ(opens in a new tab)
- ಸ್ಮಾರ್ಟ್ ಕಾಂಟ್ರಾಕ್ಟ್ ಗಳು(opens in a new tab)
- ಬಿ-ಮನಿ(opens in a new tab)
- ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಕೆಲಸದ ಪುರಾವೆಗಳು(opens in a new tab)
- ಮಾಲೀಕರ ಅಧಿಕಾರದೊಂದಿಗೆ ಸುರಕ್ಷಿತ ಆಸ್ತಿ ಟೈಟಲ್ಗಳು(opens in a new tab)
- ಬಿಟ್ಕಾಯಿನ್ ಶ್ವೇತಪತ್ರ(opens in a new tab)
- ನೇಮ್ಕಾಯಿನ್(opens in a new tab)
- ಝೂಕೋನ ತ್ರಿಕೋನ(opens in a new tab)
- ಬಣ್ಣದ ನಾಣ್ಯಗಳ ಶ್ವೇತಪತ್ರ(opens in a new tab)
- ಮಾಸ್ಟರ್ ಕಾಯಿನ್ ಶ್ವೇತಪತ್ರ(opens in a new tab)
- ವಿಕೇಂದ್ರೀಕೃತ ಸ್ವಾಯತ್ತ ನಿಗಮಗಳು, ಬಿಟ್ಕಾಯಿನ್ ನಿಯತಕಾಲಿಕೆ(opens in a new tab)
- ಸರಳೀಕೃತ ಪಾವತಿ ಪರಿಶೀಲನೆ(opens in a new tab)
- ಮೆರ್ಕಲ್ ಮರಗಳು(opens in a new tab)
- ಪೆಟ್ರೀಷಿಯಾ ಮರಗಳು(opens in a new tab)
- GHOST(opens in a new tab)
- ಸ್ಟೋರ್ಜೆ ಮತ್ತು ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್ಸ್, ಜೆಫ್ ಗಾರ್ಜಿಕ್(opens in a new tab)
- ಟ್ಯೂರಿಂಗ್ ಫೆಸ್ಟಿವಲ್ನಲ್ಲಿ ಸ್ಮಾರ್ಟ್ ಪ್ರಾಪರ್ಟಿ ಕುರಿತು ಮೈಕ್ ಹೆರೆನ್(opens in a new tab)
- ಎಥೆರಿಯಮ್ RLP(opens in a new tab)
- ಎಥೆರಿಯಮ್ ಮರ್ಕ್ಲೆ ಪೆಟ್ರೀಷಿಯಾ ಮರಗಳು(opens in a new tab)
- ಮರ್ಕ್ಲೆ ಸಮ್ ಮರಗಳ ಮೇಲೆ ಪೀಟರ್ ಟಾಡ್(opens in a new tab)
ಶ್ವೇತಪತ್ರದ ಇತಿಹಾಸಕ್ಕಾಗಿ, ಈ ವಿಕಿಪೀಡಿಯವನ್ನು ನೋಡಿ(opens in a new tab).
ಎಥೆರಿಯಮ್, ಅನೇಕ ಸಮುದಾಯ-ಚಾಲಿತ, ಮುಕ್ತ-ಮೂಲ ಸಾಫ್ಟ್ವೇರ್ ಯೋಜನೆಗಳಂತೆ, ಅದರ ಆರಂಭಿಕ ಆರಂಭದಿಂದಲೂ ವಿಕಸನಗೊಂಡಿದೆ. ಎಥೆರಿಯಮ್ನ ಇತ್ತೀಚಿನ ಬೆಳವಣಿಗೆಗಳು ಮತ್ತು ಶಿಷ್ಟಾಚಾರದಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಹೇಗೆ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ತಿಳಿಯಲು, ನಾವು ಈ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.