הסבר על מאגרים מוגנים, Unified Address ומפתחות צפייה ב‑Zcash

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

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

Sapling ו‑Orchard הם מאגרים מוגנים נפרדים, עם פרוטוקולים ועצי commitment נבדלים; היתרות בהם אינן מצב אחד שניתן להחליף ביניהם. Sprout היה הפרוטוקול המוגן הראשון של Zcash. מאז הפעלת ZIP 211 אי אפשר להוסיף ערך חדש למאגר Sprout, אף שעסקאות Sprout ישנות עדיין מופיעות בהיסטוריית השרשרת.

יש לציין את תאריך מצב הרשת. אינדקס ZIP הרשמי מציין כי NU6.2 היא שדרוג Mainnet האחרון שהושלם, והופעל בגובה בלוק 3,364,600 ב‑3 ביוני 2026. NU6.2 הפעיל מחדש פעולות Orchard לאחר אמצעי זמני לצמצום פגיעות ועם כללי circuit מתוקנים. NU6.3 ומאגר Ironwood עדיין בגדר הצעות טיוטה, לא כללי Mainnet פעילים. ראו ZIP 257, אינדקס ZIP וטיוטת ZIP 258.

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

כשמוציאים note, העסקה חושפת nullifier מתאים. המוציא מוכיח שהוא מכיר את ה‑note ומפרסם את ה‑nullifier; הרשת בודקת שלא נעשה בו שימוש קודם. צופים רואים nullifiers ואת עץ ה‑commitments, אך לא אמורים להיות מסוגלים לקשר nullifier ל‑commitment קודם מסוים. כך נמנעת הוצאה כפולה בלי להסתיר את כל נתוני הקונצנזוס. Sapling ו‑Orchard חולקים את העיקרון הכללי אך משתמשים ברכיבים ובהוכחות קריפטוגרפיים שונים; הוצאה מחייבת את הסמכות הפרטית המתאימה.

Unified Address (UA) הוא מחרוזת מקודדת אחת שיכולה להכיל receivers של Orchard, Sapling, P2SH שקוף ו‑P2PKH שקוף. Revision 0 הפעיל חייב להכיל לפחות receiver מוגן אחד. המחרוזת אטומה בכוונה: אי אפשר לזהות לפי המראה אילו receivers היא כוללת. ZIP 316 מבדיל בין Revision 0 לבין Revision 2 המוצע.

הארנק השולח אינו משלם לכל ה‑receivers. ב‑Revision 0 סדר העדיפות הוא Orchard, Sapling, P2SH שקוף ואז P2PKH שקוף; על השולח להשתמש ב‑receiver הנתמך בעל העדיפות הגבוהה ביותר. אם הארנק תומך ב‑Orchard הוא בוחר בו; אם לא, אך תומך ב‑Sapling, הוא יכול לבחור ב‑Sapling. לכן המאגר שבו נעשה שימוש תלוי ביכולות הארנק השולח, ולא רק במחרוזת הכתובת המוצגת.

טיוטת Revision 2 מציעה את הקידומות zu לכתובות מוגנות בלבד ואת tu לפורמטים שיכולים לכלול receivers שקופים. אינדקס ZIP הרשמי עדיין מסמן את Revision 2 כטיוטה; אין להציג את הקידומות האלה כפורמט Mainnet רגיל ופעיל. לפני השליחה בדקו בתצוגת הארנק את סוג הכתובת, הרשת וה‑receiver שנבחר.

העברה משקוף למוגן (t→z) יכולה לשלב הוצאה של UTXO ציבוריים עם יצירת notes של Sapling או Orchard. צופה בשרשרת יכול לראות את הקלטים השקופים, את השינוי במאגר השקוף ואת הערך נטו שנכנס למאגר מוגן. הוא אינו רואה את כתובת הקבלה המוגנת הרגילה ואת סכום כל note כפי שהיה רואה output UTXO שקוף. ההפקדה למאגר מוגן משאירה מידע על גבול המעבר.

בהעברה ההפוכה (z→t), כתובות וסכומים של outputs שקופים גלויים, וניתן להבחין בשינוי המתאים בערך המאגר המוגן. תשלום שיוצר notes בתוך אותו מאגר עשוי להסתיר נמען וסכום, ואילו מעבר בין Sapling ל‑Orchard עשוי לחשוף שינויים ביתרות של כל מאגר. ערך גבול פומבי לבדו אינו מזהה אדם או note ישן, אך אפשר להשוותו לסכומים, לזמנים ולרשומות חיצוניות.

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

ZIP 316 מגדיר Viewing Key כמידע הנדרש כדי לצפות בתשלומים אל כתובת. Full Viewing Key (FVK) יכול גם להציג מידע על תשלומים מהכתובת. ניתן לגזור Incoming Viewing Key (IVK) מתוך FVK, וניתן לגזור כתובת מתוך IVK. Unified Viewing Keys מאגדים פריטי מפתח צפייה עבור כמה פרוטוקולים.

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

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

הנראות תלויה במאגר ובסוג ה‑receiver. תנועה שקופה בלבד חושפת כתובות, סכומים וקישורי UTXO. תשלום מוגן מצפין את נמעני ה‑notes ואת ערכם, אבל commitments, nullifiers, זמני עסקאות ונתוני פרוטוקול עדיין מופיעים בשרשרת. מעברים בין מאגרים, תמיכה במאגרים, זמן תשלום ידוע, רשומות בורסה ומפתחות צפייה משותפים עשויים לספק רמזים נפרדים.

Unified Address אינו מאלץ כל תשלום להשתמש ב‑Orchard. ה‑receiver שנבחר עשוי להיות תלוי בגרסת הארנק, בהגדרות, במימוש ובמסלול העסקה. בדקו את התצוגה המקדימה או את תוצאת העסקה במקום להסיק פרטיות מהדבקת כתובת בלבד. [מדריך הפרטיות של Monero](/he/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) מתאר תכנון אחר; [המדריך לשימוש חוזר בכתובות Bitcoin](/he/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) משווה זאת לספר חשבונות שקוף.

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

תחילה ודאו שהארנק מחובר ל‑Mainnet או ל‑Testnet המיועדת. בבדיקת התשלום ודאו שהנמען מסר Unified Address ובדקו באיזה receiver הארנק יבחר. מחרוזת UA אינה חושפת חזותית את רשימת ה‑receivers, לכן בדקו בארנק את המאגר, הסכום, ה‑memo והעמלה. אם הנמען ביקש תשלום מוגן אך התצוגה המקדימה מציגה output שקוף, בדקו את תמיכת הפרוטוקול בשני הארנקים לפני שליחה.

כדי לבדוק עסקה קיימת, התאימו את מזהה העסקה והרשת ואז בדקו אילו מאגרים מופיעים בקלטים ובפלטים. כתובות וסכומים שקופים גלויים בסיירים ציבוריים; ייתכן שכלי שאינו תומך ב‑notes לא יציג את פרטיהן. אם נדרש מפתח צפייה, הגדירו למה ומה הוא חושף; אל תדביקו spending key או Viewing Key באתר לא מוכר. המדריך לארנקים custodial ו‑non-custodial מסביר גם מי אחראי לחתימה.

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

נניח ש‑Lee שולח 1.25 ZEC מ‑UTXO שקוף אל Unified Address Revision 0 הכולל receivers של Orchard, Sapling ושקוף. הסכום להמחשה בלבד, ואינו מציין עמלה או ברירת מחדל של ארנק. אם הארנק של Lee תומך ב‑Orchard, כלל ההעדפה של ZIP 316 בוחר ב‑receiver של Orchard. השרשרת הציבורית מראה את הקלט השקוף ואת נתוני הגבול, כגון הערך נטו שנכנס למאגר המוגן, אך לא את כתובת ה‑note המוגנת ואת הסכום שלה כ‑outputs ציבוריים רגילים.

אם הארנק של Lee אינו תומך ב‑Orchard אך כן ב‑Sapling, הוא יכול לבחור ב‑Sapling. ארנק שאינו תומך באף מאגר מוגן עשוי להשתמש ב‑receiver השקוף אם הוא זמין בכתובת ובפורמט התשלום. UA של Revision 0 חייב לכלול receiver מוגן, אך השולח בוחר רק receiver שהארנק תומך בו. לכן אותה UA עשויה להוביל למאגרים שונים ולנתוני גבול שונים בארנקים בעלי יכולות שונות.

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

• مواصفة بروتوكول Zcash v2026.7.0 (NU6.2)
• ZIP 316: العناوين الموحدة ومفاتيح العرض الموحدة
• ZIP 211: تعطيل إضافة قيمة جديدة إلى مجمّع Sprout
• ZIP 257: NU6.2 والتخفيف المؤقت لمشكلة Orchard
• ZIP 258: مسودة ترقية NU6.3
• אינדקס ZIP הרשמי: מצב Mainnet ומצב ההצעות