קרקע וירטואלית: מדוע חלקות אינן מתחברות ומאבדות בעלים
קרקע וירטואלית נשברת לא בשלב הרעיון, אלא בגל הראשון של משתמשים בקנה מידה גדול. תקלה אופיינית: שני בעלים תובעים בעלות על אותה חלקה בו-זמנית, מכיוון שמערכת החלקות הווירטואליות בודקת חפיפת גבולות רק בעת יצירת האובייקט, אך לא בעת העברת זכויות.
תרחיש שני — אי-סנכרון: הקונה רואה את החלקה כשלו, אך ברישום הזכויות על הקרקע היא עדיין רשומה על שם המחזיק הקודם, והסכסוך צריך להיות מוכרע ידנית. שלישי — נשירת עסקאות בעומס שיא: תור האישורים גדל, חלק מהפעולות נדחות עקב פסק זמן, והמשתמש אינו מבין אם קנה את החלקה או לא.
מחיר התקלות הללו גבוה מכפי שנדמה. סכסוך גבולות חלקות מפעיל גל של פניות לתמיכה, כל עסקה שנויה במחלוקת דורשת בירור ידני, והמוניטין של הפלטפורמה יורד מהר יותר משמצליחים לתקן אותה.
העומס על המרשם גדל באופן לא ליניארי: ככל שיש יותר חלקות ועסקאות, כך יקר יותר לבדוק כל חפיפה, אם היא נעשית "בכוח גס" על פני כל המפה.
שורש הבעיה — בכך שהגיאומטריה של החלקות והזכויות עליהן חיים בתת-מערכות שונות ומסתנכרנות באיחור. כל עוד בדיקת הגבולות, שריון החלקה ורישום הזכות לא יהפכו לפעולה אטומית אחת, המערכת תאבד בעלים בכל שיא.
מפרקים כיצד זה נסגר: כיצד לארגן בדיקת חפיפות ללא מעבר מלא, כיצד לאחד את רישום הזכויות והגיאומטריה לטרנזקציה אחת, וכיצד לעבור עומס שיא ללא נשירת פעולות.
ארכיטקטורת מרשם הקרקע הווירטואלית: מצבים ופשרות
מרשם הקרקע הווירטואלית אינו "טבלה עם קואורדינטות", אלא מערכת רישום זכויות: מי מחזיק בחלקה, על איזה בסיס, מה קורה בעת העברה וכיצד ניתן להוכיח את המצב בכל נקודת זמן.
ארכיטקטורת רישום החלקות קובעת שלושה דברים: מהירות הפעולות בעומס שיא, עלות אימות הזכויות עבור שירות חיצוני וסוג הכשלים שהמערכת פיזית אינה יכולה להרשות לעצמה.
היכן לאחסן את מצב החלקה
אחסון מלא on-chain מעניק שקיפות מקסימלית, אך כל רשומת קואורדינטות, בעלים והיסטוריית עסקאות נכנסת לבלוק — במכירות המוניות ובמינט זה נתקל בתפוקת הרשת.
תכנית היברידית מוציאה מטא-נתונים כבדים (גיאומטריה, טקסטורות, תיאורים) לאחסון מבוזר, ובמרשם מחזיקה את ההאש והבעלים: אישור הזכויות נשאר on-chain, ונפח הרשומות יורד בסדר גודל.
מסד נתונים entirely off-chain עם עיגון תקופתי לשרשרת זול יותר, אך אימות הזכות דורש אמון בשרת שלנו — עבור מרקטפלייס זהו צוואר בקבוק.
כיצד לאמת בעלות
הזכות על חלקה היא רשומה בחוזה בתוספת חתימת הבעלים. אנו מפרידים בין התפקידים: חוזה-מרשם מחזיק את הבעלים ואת כללי ההעברה, חוזה-בקר נפרד מאמת פעולות, והאינדקסר אוסף את המצב לתשובות API מהירות.
הפרדה זו מסירה את סוג הכשל העיקרי — מכירה כפולה של אותה חלקה: העסקה או מעבירה בעלות באופן אטומי, או מתבטלת כולה.
סקיילינג של עסקאות
מינט המוני וגלי מכירות הם אלפי פעולות בחלון קצר. באצ'ינג מאחד רשומות לעסקה אחת, וחשיפת מטא-נתונים עצלה מעבירה נתונים כבדים אל מחוץ לבלוקצ'יין. כתוצאה מכך, שיא המכירות אינו חוסם העברות רגילות של חלקות בין שחקנים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מלא on-chain | עולם קטן, ביקורת של כל פעולה | מינט יקר, תפוקה נמוכה |
| היברידי (האש on-chain, נתונים בחוץ) | מרקטפלייס, מכירות המוניות | נדרש שכבת אחסון אמינה |
| מסד off-chain + עיגון לשרשרת | כלכלה פנימית ללא קונים חיצוניים | אימות הזכות תלוי במפעיל |
שלמות הנתונים מובטחת על ידי האינדקסר, שבונה מחדש את המצב מאירועי השרשרת ומצליב אותו עם המרשם — אי-התאמה נראית מיד, ולא לאחר תלונת שחקן. מעגל כזה אנו בונים על רשתות תואמות EVM: החוזים ניידים, וארנקים חיצוניים מתחברים ללא התאמות.
שלבי יישום מערכת חלקות קרקע וירטואליות
יישום מערכת החלקות מתחיל לא בקוד, אלא בספירת מלאי: אילו נכסים כבר קיימים, היכן מאוחסנות הזכויות, כיצד מתועדת היסטוריית הבעלות. ביקורת המרשם מראה מה ניתן להעביר כפי שהוא, ומה יהיה צורך לנרמל — כפילויות רשומות, אי-התאמות בקואורדינטות, זכויות "תלויות" ללא בעלים. מאיכות שלב זה תלוי האם יהיה צורך לכתוב מחדש את סכמת הנתונים באמצע הפרויקט.
מכאן העבודה מתנהלת באיטרציות: כל אחת נשענת על השכבה הקודמת שנבדקה, ולא על הנחות.
- ביקורת המרשם והמצב הנוכחי. מאחדים מקורות: מסדי נתונים קיימים, ייצואים, שירותים חיצוניים. מתעדים את היקף, איכות ואי-התאמות הנתונים, מעריכים מה מנוקה אוטומטית ומה דורש החלטה ידנית של הבעלים.
- תכנון סכמת הנתונים. מגדירים ישויות: חלקה, בעלים, זכות, עסקה, היסטוריה. מניחים רשת קואורדינטות וכללי סמיכות כך שהחלקות לא יחפפו ולא ישאירו חורים.
- הגדרת הרשאות ותפקידים. מפרידים גישה: מי מנפיק חלקות, מי מאשר העברה, מי רק קורא. ההרשאות נבדקות ברמת הפעולות, ולא ברמת הממשק — אחרת עקיפה נמצאת בשאילתה אחת.
- מימוש פעולות עם חלקות. הנפקה, העברה, פיצול, איחוד, שכירות. כל פעולה עוברת דרך עסקה עם בדיקת תנאים מוקדמים: אי אפשר להעביר חלקה שאינה קיימת, או למכור פעמיים את אותה חלקה.
- בדיקה על תרחישים אמיתיים. מריצים שרשראות: הנפקה המונית, העברה שנויה במחלוקת, ביטול פעולה שגויה. בוחנים מה קורה להיסטוריה וכיצד המערכת מתנהגת תחת עומס.
- מסירת המערכת. פורסים בסביבת הלקוח, מוסרים תיעוד על סכמת הנתונים והפעולות, ומכשירים את הצוות. בנפרד מתעדים את נוהל השחזור ואת סדר הפעולות בעת תקלות.
הבדיקה הסופית — לא "המערכת עלתה", אלא "המערכת עמדה בתרחישים ששברו פתרונות קודמים". אם בשלב הביקורת עולים סתירות בזכויות, מטפלים בהם לפני תחילת הפיתוח: להעביר את הקונפליקט למערכת חדשה זול יותר מאשר להתמודד איתו בפרודקשן.
במה נבדל מרשם ציבורי ממעגל סגור?
מרשם ציבורי הוא פריסה ברשת פתוחה, שבה כל משתתף יכול לקרוא את מצב המרשם, לבדוק את היסטוריית העסקאות ולהשתכנע בעצמו שכללי ההנפקה וההעברה של חלקות לא שונו בדיעבד. מודל הגישה כאן נבנה על תפקידים בחוזה חכם: מנהל מנפיק חלקות חדשות, בעלים מנהל את שלו, צופה חיצוני רק קורא.
פרטיות הנתונים במקרה זה מוגבלת מעצם הגדרתה — כל מה שנרשם גלוי לכולם, ולכן למעגל הפתוח מוציאים רק את מה שממילא אמור להיות ציבורי: קואורדינטות החלקה, עובדת הבעלות, היסטוריית ההעברות.
מעגל סגור הוא רשת עם חוג מוגבל של צמתים, שאליה הגישה ניתנת בהזמנה או באמצעות חשבון ארגוני. כאן מודל הגישה מותאם ללוגיקה העסקית: חלק מהפעולות גלוי רק למפעיל הפלטפורמה, חלק — לשותפים, חלק — למשתמשים עצמם.
פרטיות הנתונים גבוהה יותר: מאפיינים רגישים (תנאי העסקה, קישורים אישיים) נשארים מחוץ לשדה הראייה המשותף. המחיר לכך — אמון המשתמשים נשען לא על בדיקה בלתי תלויה, אלא על המוניטין של המפעיל: המשתתף אינו יכול לאשר בעצמו שהכללים לא נכתבו מחדש, והוא נאלץ להאמין.
הבחירה בין המודלים היא בחירה על מה יישען האמון. אם ערך המוצר הוא בכך שאי אפשר לזייף בעלות על חלקה או לקחת אותה באופן חד-צדדי, המרשם הציבורי נותן זאת ללא ערבויות נוספות — הבדיקה זמינה לכל אחד.
אם תנאים מסחריים סגורים ושליטה על הרכב המשתתפים הם קריטיים, המעגל הסגור נוח יותר, אך את האמון יהיה צורך לבנות באופן ארגוני: באמצעות ביקורת, חשיפת כללים ונהלים שקופים למשתמשים.
בפועל המודלים אינם סותרים זה את זה. חלק מהמצב — הזכויות על החלקות והיסטוריית ההעברות — מוציאים למרשם ציבורי, ואת הנתונים הרגישים והלוגיקה הפנימית של הפלטפורמה מחזיקים במעגל סגור, ומקשרים ביניהם באמצעות אישורים קריפטוגרפיים. כך נשמרת בדיקה בלתי תלויה של הבעלות ובמקביל נסגרת פרטיות הנתונים שהרשת הציבורית אינה יכולה לספק.
מקרה בוחן: כיצד בוטל סוג הכשלים בהנפקת חלקות
הלקוח הגיע עם מרקטפלייס פעיל של קרקע וירטואלית: חלקות נמכרו, אך בערך כל עסקה שמינית נתקעה. הקונה שלח תשלום, העסקה נתלתה בממפול, ובזמן הזה החלקה הספיקה לעבור לאחר — קונפליקט קלאסי על אותו טוקן בהיעדר אטומיות בין התשלום להעברת הבעלות. בנוסף הצטברו מחלוקות על גבולות: שתי חלקות סמוכות חפפו בכמה מטרים, ולא היה במה להוכיח מי צודק.
מה שינו
ההנפקה הועברה לסכמה "שריון → תשלום → סיום": עם תחילת העסקה החלקה מסומנת כתפוסה בחלון מוגבל, ורק תשלום מאושר מסיר את השריון ומעביר את הבעלות. אם החלון פג — השריון מוסר אוטומטית, הקונה אינו מאבד כספים, והחלקה חוזרת למכירה. זה ביטל את המרוץ על אותו טוקן.
הגבולות תוקנו במבנה החלקה עצמה: קואורדינטות ושטח נכתבים לרשומה בלתי ניתנת לשינוי בעת ההנפקה, ולא נשמרים בנפרד מהבעלות. חפיפה נחסמת כעת בשלב ההנפקה — המערכת אינה מאפשרת ליצור חלקה שחופפת לקיימת.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הנפקות מוצלחות | ~87% | 99,6% |
| זמן אישור העסקה | דקות, עם תקיעות | שניות יציבות |
| מחלוקות על גבולות | סדירות, בירור ידני | בודדות, נפתרות אוטומטית |
בנפרד נסגר הרולבק: אם הסיום לא עבר, המצב חוזר לשריון, ולא ל"חצי עסקה". זה אותו סוג כשל שדרש בעבר בירור ידני וערער את האמון בפלטפורמה.
לוגיקת השריון ובדיקת הגבולות נבנו על חוזים חכמים עם אימות חיצוני של תשלומים — Chainlink להעברת נתונים מאומתים על התשלום לחוזה. ללא אורקל אמין, השריון היה מוסר על סמך אות לא מהימן, והמרוץ היה חוזר.
התוצאה עבור הלקוח: הפעולות הפסיקו להיתקע, מצבי המחלוקת על הקרקע יצאו ממצב ידני, וזמן האישור הפך לצפוי — הפלטפורמה עמדה בגידול במספר העסקאות ללא בנייה מחדש של הליבה.
תאימות, הגירה וחזרה לאחור: ספקות טכניים
קרקע וירטואלית כמעט תמיד חיה מעל מוצר קיים: חשבונות, תשלומים, קטלוג אובייקטים והרשאות משתמשים כבר קיימים, והשאלה אינה "מאפס או לא", אלא "כיצד לשלב את מרשם החלקות כך שלא נצטרך לכתוב מחדש חצי מהמערכת ותהיה דרך חזרה". להלן מה שנבדק לרוב לפני ההתחלה.
מה יקרה אם לאחר ההשקה נצטרך לחזור לגרסה קודמת?
את החוזים פורסים דרך שכבת פרוקסי: הלוגיקה מתעדכנת בנפרד מהאחסון, ולכן חזרה לאחור היא החלפת מצביע לגרסה הקודמת, ולא פריסה מחדש. מצב המרשם אינו הולך לאיבוד: נתוני החלקות והיסטוריית העברות הבעלות נמצאים באחסון בלתי ניתן לשינוי ואינם תלויים בקוד.
לפני כל עדכון אנו מבצעים צילום מצב ומריצים את ההגירה על עותק — אם הבדיקות אינן עוברות, הגרסה אינה עולה לפרודקשן.
מה אם יש לנו בסיס משתמשים ותשלומים משלנו? מרשם החלקות מתחבר לחשבונות שלכם דרך שכבת גישה: ההרשאות על החלקה נקשות למזהה המשתמש שלכם, ולא לארנק נפרד. התשלומים נשארים בקונטור שלכם — המערכת מקבלת רק אישור על הפעולה.
כיצד מועברות חלקות שכבר נמכרו? ההגירה מתבצעת במנות עם בדיקת סכומי ביקורת: לפני ההעברה מתעדים את המצב הנוכחי, לאחריה — משווים את הכמות והבעלים. אי-התאמה אפילו בחלקה אחת עוצרת את המנה.
למי יש גישה לניהול? התפקידים מופרדים: מנהל מרשם, מפעיל הנפקה, מבקר עם גישה לקריאה בלבד. כל פעולה נרשמת ביומן עם ציון התפקיד והזמן.
לאחר המסירה הלקוח מקבל לידיו:
- תרשים מרשם החלקות ומודל זכויות הבעלות;
- קונפיגורציות פריסה וסביבות (בדיקה, פרודקשן);
- מדיניות תפקידים ומטריצת הרשאות;
- נוהל הגירת נתונים והליך חזרה לאחור של הגרסה;
- תיאור האינטגרציות עם החשבונות והתשלומים שלכם;
- הוראות תחזוקה וניטור המרשם;
- יומן הבדיקות ותרחישי הבדיקה שבוצעו.
תארו את המערכת הנוכחית שלכם ואת היקפי הנתונים — נחזור עם הערכה, תוכנית הגירה ותרשים חזרה לאחור המותאמים לקונטור שלכם.