פיתוח בלוקצ'יין דרך עיניו של מפתח Backend

צהריים טובים לכולם! אני עוסק בפיתוח Backend כבר די הרבה זמן, ובשנים האחרונות, אני כותב יותר ויותר פרויקטים שונים של בלוקצ'יין (Solidity on EVM). הצלילה לבלוקצ'יין לא הייתה קלה עבורי, והמוח האחורי שלי התקלקל כמה פעמים, אז החלטתי לחלוק את דעתי לגבי המעבר לפיתוח בלוקצ'יין.

בלוקצ'יין היא טכנולוגיה מאוד מגניבה שיכולה להניע את העולם שלנו קדימה. אבל לעת עתה, הרבה אנשים משתמשים בו כדי לקנות-למכור-להוכל-הונאה-להגביר. אני לא אחשוב ולא מתכוון לשקול קריפטו כנכס.

כן, סרטונים ופוסטים רבים ושונים אומרים, "הנה, קריפטו כזה וכזה יכול לצמוח עכשיו, והקריפטו הזה וכזה נפל. חבר'ה, בואו נשקיע, בואו נקנה...” אני לא אגיד לכם כלום על זה.

אני אגיד רק דבר אחד - כדאי להימנע מקריפטו בשביל להרוויח כסף. אם אתה מפתח, עדיף לנסות להרוויח כמפתח ולא להסתבך בהשקעות. ואם אתה באמת רוצה להשקיע, אל תכנס לקריפטו.

על בלוקצ'יין ולמה זה מעניין

כדאי להתחיל בהערה חשובה. בלוקצ'יין זה לא מטבע קריפטוגרפי. בלוקצ'יין היא הטכנולוגיה שעליה בנוי מטבעות קריפטוגרפיים ולקרוא למטבע קריפטוגרפי בלוקצ'יין זה כמו לקרוא לכל תעשיית הפיתוח Javascript . כן, נראה ש-JavaScript הוא מקרה פיתוח מיוחד, אבל כשדנים בפיתוח, אנחנו לא מתכוונים ל-JavaScript. למרות שחלק מהאנשים מתכוונים רק ל-JavaScript...

הולך לבלוקצ'יין בשביל הכסף

הדבר הראשון שעולה על הדעת הוא כסף. מפתחי בלוקצ'יין מקבלים שכר די טוב. אני אישית פתחתי משרות פנויות כאלה. הגבתי באופן אישי למשרות פנויות כאלה, שבהן אתה יכול להשיג יותר מאותו מפתח backend עבור אותה כמות זמן המושקעת ביום בעבודה. מפתחי בלוקצ'יין שווים את משקלם בזהב בסטארט-אפים מבוססי בלוקצ'יין. מפתח בלוקצ'יין טוב במיוחד!

מיהו מפתח אחורי טוב?

להפוך למפתח אחורי טוב הוא בלתי אפשרי מבלי להפיל או לתקן פרוד. אולי אני פשוט לוזר ולומד רק דרך חוויות שליליות, אבל זו התיאוריה שיש לי:

1. אם מפתח הקצה האחורי מנוסה, אז הוא הפעיל פתרונות בפרוד.
2. אם הוא הפעיל אותו ב-Prod, אז הוא יודע איך הוא פועל ויודע מה קורה למוצר בעומס.
3. אם הוא שמר על שירותים בעומס, אז הוא תפס זמני השבתה ותקיעות שירות.
4. ואם הוא נתפס תאונות שירות, הוא כנראה אסף אותן.

אתה לא יכול להחליף ניסיון עם כישלון, אבל חווית הכישלון מאפשרת לך להבין שיש לך ניסיון. קשה להפוך למפתח בלוקצ'יין טוב מבלי להפסיד כסף:

• אם עדיין לא גנבו לי כסף מהחוזה שלי, זה אומר שלא השקתי משהו עם כסף אמיתי (לפחות 1000$ בחוזה שלי).
• אם לא השקתי משהו בכסף אמיתי או רק ברשתות בדיקה (עם כסף מזויף), אז אין לי מושג מה מצפה לי בעולם הרעיל של הבלוקצ'יין.
• אם אני לא יודע מה מצפה לי, אני נכווה בהשקה הראשונה, וזו שאלה של הצוות/חברה שמוכנים לקחת את הסיכון להיות המשלם הראשון על הטעות שלי.

נכנסים לבלוקצ'יין בשביל הטכנולוגיה

התמונה למעלה מציגה את המטוס הראשון של האחים רייט בעולם, טס די גרוע. אבל הוא טס, ובימיו, היחס של האדם הממוצע למטוסים היה בערך כך:

• יָקָר
• לֹא נוֹחַ
• לא נוח, לא מובן

ועכשיו, תעשיית התעופה היא חלק נפלא מחיינו, ומחברת אנשים בכל רחבי כדור הארץ תוך מספר שעות. הלוגיסטיקה נמצאת כעת ברמה שהאחים רייט לא חלמו עליה! כל העולם חי אחרת בגלל מטוסים.

הייתי אומר את אותו הדבר על בלוקצ'יין עכשיו - זה יקר ולא נוח ולא ברור למה. עד שהייתי שקוע בפיתוח בלוקצ'יין, זה נראה לי כמו משהו חסר תועלת לרמות משקיעים (=אוגרים). אבל אם מסתכלים על זה מהצד השני, אפשר לאחסן כל עובדות בצורה מבוזרת ללא אפשרות לחבל. ה"ללא אפשרות לחבל" הוא פרט חשוב.

אבל אבוי, האסוציאציות עם המילה "בלוקצ'יין" הן די משעממות ומונוטוניות:

• ביטקוין
• הַשׁקָעָה
• הונאה
• ETH, Ripple, {הכנס שם מטבע}
• בועה שעומדת להתפוצץ

אם נזרוק צרור של כסף נייר לתוך הכיריים, התנור יישרף היטב, והכסף אפילו יתן חום לזמן מה. אבל זה אבסורד.

וכך זה עם הבלוקצ'יין. השימוש בו רק עבור כסף וקריפטו זה רע, אבל הדבר השני עדיין לא השתרש...

אחד המניעים העיקריים של כל פיתוח מוצר הוא כסף. אם יש משהו שאפשר לעשות עליו כסף טוב וחזק, אז ה"משהו" הזה יפותח באופן פעיל. ובגלל זה, עד כה, פרויקטים פיננסיים המבוססים על בלוקצ'יין באמת מבוססים על להרוויח כסף בשביל מישהו להרוויח כסף ולהפסיד כסף בשביל מישהו אחר.

תורת פיתוח הבלוקצ'יין

ביזור

מה ההבדל בין שירות ריכוזי למבוזר? נתחיל עם מערכת מרכזית. יש אני ועוד מישהו, והחלטנו להשתמש בשירות בינינו, כמו בנק או ספק אחר, כדי להקל על העברה.

בואו נדמיין שיש לנו בנק, שהוא שירות ריכוזי. אני מצווה על הבנק הזה: "אנא העבר 100 דולר לאדם הזה". הבנק רושם שיש לי 100 דולר פחות, ולמישהו אחר יש 100 דולר יותר.

אבל מה הבעיה בשירות הריכוזי? יש בעלים מאחורי השירות הריכוזי הזה, לא? בדרך כלל, כמה חברות גדולות, אחזקות, זה לא משנה; במקרה שלנו, שיהיה זה אדם אחד. אדם אחד זה יכול לומר: "בוא נעשה את זה. תן לאלכס לשלוח 100 דולר, אבל אף אחד לא יקבל את 100 הדולרים האלה. אני צריך אותם יותר".

לשירותים מרכזיים יש את הבעלים שלהם. הבעיה היא שהבעלים יכול לקבל החלטות שליליות, לקחת כסף. וזה יכול להיות לא רק על "לקחת את הכסף לעצמך". לדוגמה, אתה יכול לכתוב, "יש לנו 100,500 דולר בבנק", ולקוות שכל המפקידים לא ילכו אחרי הכסף הזה... כפי שקרה עם SVB ובנקים אחרים שמתו.

הביטקוין הומצא כדי לבזר את ניהול הכסף.

שירות מבוזר בנוי על רשת של צמתים שבה כל צומת מאחסן ומעביר מידע. במילים פשוטות, הצמתים הסכימו על איזה מידע נחשב לנכון ומה לא וכיצד אנו מאחסנים אותו.

אנחנו יכולים לצייר אנלוגיה לחדר - אדם אחד צועק את המידע שהוא רוצה שהאחרים ישמרו. לאחר מכן, כל מי שנמצא בחדר עובד עם המידע שאוחסן לאחר הצעקות.

לדוגמה, בלוקצ'יין יכול לאחסן ולשדר הודעות או מידע על העברות כספים. המשתתפים ברשת מאמתים את המידע לפני הקלטתו.

באנלוגיית החדר, אני צועק, "אני מעביר 100 דולר לסם." כולם רושמים שיש לי 100 דולר פחות, ולסאם יש 100 דולר יותר. אם פתאום, לפני ההעברה, יש לי פחות מ-100 דולר, אף אחד לא ירשום את העסקה.

חוזים חכמים

בבלוקצ'יין ניתן ליצור חוזים חכמים בשפת Solidity (במקרה של בלוקצ'יין ב-EVM). חוזה חכם הוא תוכנית הפועלת ברשת הבלוקצ'יין. הוא עשוי להכיל מנגנוני אימות, טיפול בשגיאות ופונקציות אחרות.

שוב, במקרה של החדר שבו אנחנו צועקים פקודות, חוזה חכם הוא שאני נותן לכל משתתף בחדר את קוד התוכנית מראש: איך להגיב לפקודות שלי, מה לבדוק ומה לשמור. ואז אני צועק, "הפעל את התוכנית עם הפרמטרים האלה". לאחר מכן, כולם ממלאים אחר ההוראות. דוגמה לחוזה פשוט וחכם הוא אחסון מידע עם פונקציות של הוספה וקבלה של נתונים. קוד החוזה מורכב לקוד בתים ומועבר למשתתפי הבלוקצ'יין לביצוע.

כיצד אנו מטפלים בבקשות המסוימות שישלחו לחוזה החכם הזה? אם נצייר אנלוגיה ל-backend, זה שירות שיכול לעבד בקשות POST ו-GET. POST מאחסן מידע. GET here שולח בחזרה את המידע ששמרנו. בדרך כלל כך בנוי כל אחורי.

במהלך הפיתוח שלי ב-backend, התרגלתי מאוד לסידור שה-API, מסד הנתונים וכל מה שקשור לאחסון ועיבוד נתונים מתרחשים בצד שלי. ואני כבר, כאילו מאחורי קיר, מספק ממשק למשתמש לעבוד עם הנתונים האלה לפי תרחיש שהוכן מראש.

לדוגמה, משתמש 1 בא ושומר תוכן (פוסט, למשל) בשיטת POST. לאחר מכן, משתמש 2 בא ומחזיר את התוכן הזה בשיטת GET. המשתמשים לא יודעים היכן ואיך הוא טמון - הקצה האחורי הוא קופסה שחורה עבורם.

וכאן הגענו לחלק חשוב מאוד של הבלוקצ'יין. בואו נחזור לדוגמאות שלנו של צמתים או אנשים שעומדים בחדר. נניח, באמצעות אנלוגיה ל-backend, יש לנו את הדברים הבאים בכל פעם: אני זורק שיטת "ADD" לתוך הבלוקצ'יין, ואז כולם מתקשרים מקומית לשיטה ואז יכולים לקחת מידע מהעותק שלו של הבלוקצ'יין.

אז, יש לנו חבורה של עותקים שונים ברשת שמהם צמתים לוקחים מידע. הבעיה בבלוקצ'יין היא שעלינו לשלם כסף אמיתי עבור כל פעולת כתיבה. על זה משלמים מטבע הרשת, שאפשר לקנות בכסף אמיתי (או לכרות, אבל לא על זה אנחנו מדברים היום).

אם נשווה בלוקצ'יין ו-backend, התמונה היא כדלקמן:

• בשירותים קונבנציונליים אנו כותבים בחינם, קוראים בחינם ובתלות
• בבלוקצ'יין כותבים בתשלום וקוראים בחינם ובאופן עצמאי

לדוגמה, לטלגרם יש מסד נתונים מרכזי. אנחנו תמיד יכולים לגשת אליו בחינם ולהוריד את ההודעות, התמונות, הסרטונים וכו' שלנו. אבל אם השרתים של טלגרם יורדים לפתע, לא נוכל לגשת אליו.

אנחנו צריכים לשלם עבור המכונה הוירטואלית EVM כדי לבצע כמה פקודות חוזה חכמות, כולל כתיבת מידע לבלוקצ'יין. הוא מבצע כמה חישובים, מוסיף משהו, מכפיל, מכפיל, מכפיל, ובסופו של דבר, מופיע חפץ חדש באחסון הבלוקצ'יין, שמתעדכן בכל הצמתים המשתתפים בבלוקצ'יין.

כל משתתף ברשת יכול להריץ צומת מלא עם מאות גיגה-בייט של נתוני בלוקצ'יין ולעבוד איתו באופן מקומי. אתה יכול גם להשתמש בגרסה קלת משקל של הצומת, שלא תשמור את כל הבלוקצ'יין, אבל אתה יכול לגשת לצמתים המלאים ברשת ולאחזר דרכו את המידע הדרוש.

הרעיון הוא שכל כניסה בבלוקצ'יין היא בלוק שמכיל חבורה של עסקאות שבהן מתרחשים שינויים במצב הבלוקצ'יין. כל בלוק עוקב תלוי בקודם בשרשרת המבוססת על אלגוריתמי גיבוב.

באופן כללי, זה בסיסי, אבל כדאי לזכור - צריך לשלם על כל עיטוש אם הנתונים משתנים. אגב, גם פריסת חוזה היא שיא בבלוקצ'יין ואינה זולה!

פריסת חוזה חכם

בעולם הקצה האחורי, אני רגיל בערך למחזור החיים של פיתוח התכונות הבא:

• כתב את הקוד
• השיק אותו ב- Gitlab
• GitLab CI מריץ בדיקות, בודק הכל
• אם הכל בסדר, CI מתחיל לפרוס גרסה חדשה של היישום לשרת

כלומר, אנחנו רגילים לעבוד כך, וזה קורה בחינם. אמנם בחינם בתנאי, כי אנחנו כן משלמים על השרתים. מה עם בלוקצ'יין?

במקרה של בלוקצ'יין, עלינו לכתוב את הקוד החדש של ה"אפליקציה" שלנו (חוזה חכם) לבלוקצ'יין. כפי שכתבתי למעלה, עלינו לשלם עבור כל רשומה. לפני שאנחנו מבצעים עסקה לחוזה החכם שלנו, אנחנו צריכים לבצע עסקה עם הצבת החוזה החכם.

לאחר מכן, שרת הלקוח/שירות ייצור קשר עם כל אחד מהצמתים כדי לקבל או לשמור מידע בחוזה.

צריך להודיע למספר עצום של צמתים - "חבר'ה, הנה קוד הבתים של החוזה שהאלגוריתמים שלו צריכים להיעשות על העסקאות שלי". חובה לוודא שאותו קוד יופיע בכל הצמתים שלומדים את הבלוקצ'יין, והוא יתבצע באותו אופן, ללא קשר למי שקורא לו וללא קשר לאיך שהוא נקרא. המכניקה תהיה זהה ולא משתנה. יתר על כן, אין שום סיכוי שניתן לשנות איכשהו את החוזה החכם כך שיעבוד אחרת בכל אחד מהצמתים.

להלן דוגמה לעסקה שבה הפקדתי חוזה לרשת ETH לפני די הרבה זמן.

זה היה חוזה מבחן שמעולם לא נעשה בו שימוש אמיתי. שילמתי 200 דולר ב-ETH עבור הפריסה שלו. כלומר, עדיין לא עשינו שום דבר עם החוזה הזה - לא בקשה אחת, אבל 200 דולר כבר הוצאו. אני עדיין עצוב כשאני זוכר את הפריסה השגויה הזו של החוזה הלא נכון...

אחסון נתונים

בואו נדבר על אחסון נתונים. כולנו רגילים שיש לנו PostgreSQL , MySQL , MongoDB , Redis ושירותים אחרים בקצה העורפי המאפשרים לנו לעבוד עם נתונים בצורה נוחה. במקרה של בלוקצ'יין, אין דבר כזה אפילו קרוב.

בבלוקצ'יין, האחסון מיושם כמו משתנים במחלקה בשפות אחרות. כלומר, רק ערכי מפתח או מערכים. אין טבלאות יחסים עם קישורים נוחים, וכן הלאה. פשוט - כתבו למשתנה ותשמחו.

כרגע, אני לא מכיר דרך אחרת לארגן אחסון בבלוקצ'יין. ובכן, אולי המצב כבר השתנה; אולי כשאתה קורא את זה, יש דרך כזו - כתוב בתגובות.

למשל, אם אנחנו רוצים לאחסן לא רק במערך? ואנחנו רוצים לאחסן מידע לפי מפתח - יש מיפוי בשביל זה.

סימן הדולר נמשך מסיבה כלשהי - עמלת הרשת תילקח עבור כל סט.

כאבים וכאבים

בלוק זה, אדון בדברים שהפתיעו או הכעיסו אותי. יש הרבה יותר ממה שיש במסמך הזה, אבל אני אשתף בדברים הראשונים שפגעו בי לראשונה בתרגול שלי.

חשוב לציין שרוב ה"כאבים" מובנים מסיבה הגיונית כלשהי. אבל זה לא מבטל את הכאבים של המוח האחורי שלי.

לדוגמה, אני רגיל לעובדה שאנחנו יכולים לעבור בקלות על כל האלמנטים של כל דבר. זה לא משנה אם זה מערך או אובייקט או מפה. בסולידיטי לצורך כך נצטרך לאחסן בנפרד מערך של כל המפתחות ולאחר מכן, במידת הצורך, לעבור על כולם ולשלוף אלמנטים מהמפה עבור כל מפתח. ובכן, אנחנו גם מבזבזים גז על כתיבה נוספת למערך המפתחות הזה ועל האתחול שלו.

גם אנחנו לא יכולים להשיג את כל הדברים השימושיים למיון המפתחות.

רישום

גם המצב עם רישום הוא לא נעים. אני רגיל לנפות באגים דרך ה-debugger בסביבת הפיתוח, אבל כאן כדאי לשכוח אפילו מרישום רגיל.

ב-Typescript, אני רגיל לכתוב console.log(a) ומיד לקבל את הפלט בקונסולה. ב-Solidity, יש console.log , שפועל רק כאשר הוא פועל בסביבת הפיתוח המקומית של Hardhat . ומה שיפה הוא שאחרי שפיצלתי את מה שאני צריך, אני צריך למחוק את כל רישום הרישום הזה לפני פריסת החוזה כי אחרת, החוזה שוקל יותר ועולה יותר לפריסה, והוא לא יעבוד בכלל על ה-prod .

בסוף מסתבר שכאשר אנחנו מנהלים את הפרויקט כבר בקרב, אנחנו רוצים לראות מה לא בסדר, אנחנו לא יכולים לראות מה השתבש. אבל אנחנו יכולים לראות מה הלך כמו שצריך. יש מערכת אירועים בתוך חוזים חכמים. הנה דוגמה: נניח שאנו רוצים לקיים אירוע שבו פריט חדש נוסף תחת האינדקס הזה עם הערך הזה.

אנו קוראים לאירוע הזה בתוך שיטת set , ונוכל לראות את היומנים רק כאשר הוא מבוצע בהצלחה. אם משהו השתבש, היו לך קריאות מרובות לחוזים, או שהיתה לנו קריסת עסקה, אז היומנים לא נשמרים גם בגלל שהמידע בבלוקצ'יין מתגלגל לאחור.

נניח שאתה משתמש בשרשרת של מספר חוזים חכמים. קראתם בחוזה הראשון כמה אירועים, ואז נקרא החוזה השני, שקורא אירועים אחרים, ואז נופל כל מה שנקרא בתוך החוזה השני. הכל יימחק בדיוק לגמרי אחת ולתמיד.

עלינו להיות זהירים מאוד כאשר אנו רוצים לרשום את מה שקורה בתוך הבלוקצ'יין ולזכור כי רישום רגיל, אליו אנו רגילים, פשוט לא זמין לנו כאן.

דבר מגעיל נוסף הוא שאנחנו לא יכולים לקבל מידע מהעסקאות שלנו בפונקציית כתיבה. אם נעשה עסקה שכותבת משהו לבלוקצ'יין (כלומר עסקה בתשלום), return לא תיתן כלום לשירות שלנו שמשתלב עם החוזה החכם. החזרה זו פועלת רק במסגרת החוזה החכם עצמו או בפונקציות view (חינם).

לדוגמה, נרצה שכאשר נוסיף ערך חדש לבלוקצ'יין שלנו, אולי נרצה לגלות את גודל האחסון לאחר השמירה (צילום מסך למעלה). כלומר, אנחנו יכולים לגלות רק דרך אירועים מה בדיוק התווסף. וכדי לעשות זאת, עלינו למשוך אירועים שהופעלו בתוך אותה עסקה.

עבודה עם מיתרים

הייתה כאן הפתעה עבורי - אי אפשר לעבוד עם מיתרים כרגיל. הבלוקצ'יין לא נוצר עבור מחרוזות. נעבור לדוגמאות.

הקוד שלהלן יעבוד ללא בעיות.

והקוד הזה לא יעבוד יותר:

אני כבר מזמן רגיל לעבוד רגיל עם מחרוזות, לשנות תווים במחרוזות, לחתוך מחרוזות, לשרשר אותם - כל זה לא זמין מחוץ לקופסה. אין גם אפשרות להציג את אורך המיתר. כלומר, הקוד הזה לא יקמפל:

אם אתה באמת צריך את האורך של מחרוזת, אתה יכול להמיר אותה לבייטים ואז לספור את מספר הבתים. אבל הבעיה היא שחלק מהתווים המיוחדים אינם מומרים לבייטים 1v1. וחלקם פשוט לא מומרים והעסקה עלולה לקרוס.

אתה יכול בסופו של דבר לכתוב חוזה חכם שמטפל במחרוזות ובבדיקות על מחרוזות רגילות. לאחר מכן, תגיע מחרוזת שלא תעובד, והכל יקרוס, או שאורך המחרוזת ייספר בצורה לא נכונה בגלל תווים מיוחדים.

המסקנה על מיתרים פשוטה: אל תעבדו עם מיתרים ואל תסתמכו על מיתרים בתוך החוזה. אם חשוב לשמור מחרוזות, אז לשמור בתים ולהסתמך על בתים, ולהמיר מחרוזות לבייטים בשירות עצמו.

בעיה בשיחה חיצונית

המורכבות הבאה, שהיא הרחבה של התכונה העיקרית של הבלוקצ'יין, היא הבידוד. כל הנתונים שנמצאים על הבלוקצ'יין נולדים בתוך הבלוקצ'יין או מועברים אליו מבחוץ. אבל הבלוקצ'יין עצמו לעולם לא יכול לדפוק על העולם החיצון - רק חוזים חכמים אחרים.

הבעיה היא שכל פקודות החוזה החכמות מבוצעות אצל כל משתתף ברשת. ואתה לא יכול לסמוך על מקור חיצוני, שכן אתה לא יכול להיות בטוח שאותו מידע יתקבל בכל צומת. יקרה שלכל צומת תהיה גרסה שונה של הבלוקצ'יין עם נתונים שונים והבלוקצ'יין יקרוס.

והמשימה הטריוויאלית של "להשיג את הטמפרטורה הנוכחית בחוץ" הופכת למשהו בלתי אפשרי. אמנם אנחנו לא תמיד צריכים את מזג האוויר, אבל נתונים מסוימים (כמו שערי מטבע או המצב הנוכחי של מערכת חיצונית כלשהי) הם חיוניים. הפתרון טמון בגישה הבאה:

1. יש לנו חוזה מפעיל, שבו השירות שלנו שולח משימה כמו "הגש בקשה לשרת הזה עם פרמטרים כאלה ואחרים".
2. חוזה פולט אירוע
3. Backend נפרד נרשם לאירוע הזה, שואב מידע מהאירוע, שאומר "לאן ועם אילו פרמטרים לשלוח את הבקשה" והתשובה "שים את זה כאן בחוזה הזה".
4. השרת שולח את הבקשה עם הפרמטרים הנכונים, מקבל את התגובה
5. השרת שולח את התגובה לחוזה הנדרש.
6. מה שקורה אחר כך הוא מה שצריך לקרות עם הנתונים האלה.

מסתבר שזו שרשרת כל כך ארוכה. העצוב של הסיפור הוא שהכסף נלקח בבקשה הראשונה שלי בטופס "לך לי על בקשה כזו" ובבקשה השנייה, שכבר נעשית על ידי השרת שביצע את הבקשה.

לדוגמה, זה לוקח לנו 50 אלף גז עבור כל צעד. אנחנו מתחילים את העסקה, שמים 50k GAS LIMIT, וחושבים שנהיה בסדר. אבל, למשל, המכניקה של שמירת מזג האוויר החדש משתנה - כעת, כשהטמפרטורה היא מעל 10 מעלות, עלינו להעביר כסף לאחד המשתתפים. ההיגיון מתרחב, ועכשיו זה ייקח, למשל, 80 אלף גז לכל עסקה.

בסופו של דבר, כבר בעסקה השנייה, כל הרשת קורסת בגלל מחסור בגז לעסקה. "גן ירק" שכזה סביב קריאות חיצוניות הופך פרויקטים כאלה למסובכים יותר. סביר להניח שאם יש לך חיבור קשה לעולם החיצון, אל תבחר בבלוקצ'יין לפרויקט שלך.

אין גם אקראיות נורמלית שלא ניתן לקבוע מראש. האקראיות הזו מסופקת גם על ידי ספקים שונים "כמו שהוא" - רק ערך אקראי נכתב בקביעות בחוזה החכם. אבל זה מסוכן לסמוך על דבר כזה עבור פרויקטים פיננסיים אמיתיים.

העובדה שהערך של המשתנה block.timestamp נקבע על ידי כורה הבלוק ראויה לתשומת לב מיוחדת. כמובן שקשה להעלות על הדעת שהכורה תדע מראש שהוא זה שכורה את הבלוק, והוא יכול להחליף את הזמן. ובכל זאת, יש אפשרות היפותטית. הסכנה הזו רלוונטית בהקשר של 15 שניות, ואם נסתמך על דקות ומרווחי זמן גדולים, אין בעיה כזו.

בעיות אבטחה

אני לא מתכוון לדבר הרבה על אבטחה. אבל אדגיש היבט חשוב: הכל בבלוקצ'יין גלוי לכולם. הדבר היחיד שאינו נגיש לאחרים הוא המפתח הפרטי שלך. קוד החוזה החכם מופץ בגלוי על מנת לעבור ביקורת וכדי שמשתמשי חוזים חכמים יוכלו לסמוך עליו.

הליך ביקורת פירושו חברה שנשכרה כדי להסתכל על קוד החוזה החכם ולוודא שהחוזה הספציפי הזה פורסם תחת כתובת זו. נושא אבטחת החוזה נבדק, והוא עושה את מה שהיזמים מצהירים. בשלב הבא, חברת הביקורת מפרסמת באתר האינטרנט שלה מידע כמו "החוזה הזה אומת על ידינו - ניתן לסמוך עליו".

משתנים בלתי ניתנים לשינוי

אבל גם אם קוד החוזה לא מסופק, ניתן לפרק אותו בקלות. לדוגמה, לקוד הבא יש משתנה בלתי ניתן לשינוי - הוא פשוט מוחלף בכל מקום בקבוע בקוד למטה.

לאחר פריסת חוזה זה ופתיחתו דרך ה-decompiler, אנו רואים את הדברים הבאים:

כלומר, אנחנו מקבלים את הערך הזה של המשתנה באופן מיידי.

משתנים פרטיים

אני רגיל להיות רגוע ב-backend, והערך של משתנים פרטיים לקריאה ללא גישה לזיכרון יהיה בעייתי. זה אותו דבר כאן - רק שלכולם יש גישה ל"זיכרון".

קראנו amount המשתנה פרטי. פרוס את החוזה החכם ולאחר מכן משוך את הערך שלו על ידי קטע קוד פשוט:

אתה יכול בסופו של דבר לשלוף כל דבר כך. אז אל תחשוב על אחסון משהו רגיש בחוזה החכם!

פריסת חוזה חכמה

זה בעצם בלתי אפשרי להחזיר את השינויים שלך לאחור. חוזה חכם מוקצה פעם אחת, ולא ניתן לשנות דבר. זה יישאר בבלוקצ'יין עד סוף הזמן ואחר כך קצת.

חוזים חכמים הניתנים לשדרוג

לכן צריך לכתוב הכל נכון וטוב בבת אחת. אני לא יכול לעשות את זה, אז הגעתי במהירות לפתרון מעניין - חוזים ניתנים לשדרוג . המכניקה שלהם עובדת כדלקמן.

1. הגרסה הראשונה של החוזה (חוזה V1) פורסמה

2. חוזה פרוקסי מתפרסם ויש לו את המשימה הבאה: להעביר את כל הבקשות 1v1 לחוזה V1 או להשתמש באחסון משלו ולהשתמש רק בלוגיקה מחוזה היעד.

3. יתר על כן, המשתמש מתקשר עם חוזה ה-proxy באותו אופן כמו עם החוזה הראשי.

   אם יש צורך לעדכן את החוזה, המנהל פורס את חוזה V2 ובאמצעות חוזה אדמין, אומר ל-proxy-contract שהיישום נמצא כעת בכתובת של חוזה V2.

4. לאחר מכן, המשתמש גם מתקשר עם ה-proxy, והמכניקה מחוזה V2 כבר בוצעה.

5. לאחר מכן, המשתמש גם מתקשר עם ה-proxy, והמכניקה של חוזה V2 כבר מבוצעת.

למנגנון זה יש מספר מגבלות וטריקים. לדוגמה, לא ניתן לשנות משתנים מהגרסה הקודמת בגרסה החדשה של החוזה. אם כבר אין צורך במשתנה, עדיין יש להשאירו ולפרק אותו בחוזה החדש.

כמובן שלפתרון זה ורבים אחרים יש כבר דרכים לעקיפת הבעיה. הספק העיקרי של פיתוחים אלה הוא OpenZeppelin . אז, למרבה המזל, אין צורך להמציא את הגלגל מחדש.