Single-account-restriction and capped-transfers clearly need account-style live-position-checking — is this specific holder already over a threshold, right now.
نشر
--
Daniyaa
·
--
صاعد#dusk $DUSK @Dusk
تعتمد عمتـي على دفـترين منفصلين لسجلّات أعمالها العقارية المؤجرة — أحدهما لتتبّع أي وحدةٍ بعينها تابعة لأي مستأجر، والآخر لتتبّع إجمالي الإيجار المحصّل هذا الشهر. سألتُها لماذا لا تستخدم دفترًا واحدًا فقط. قالت إن الملكية الفردية والأرصدة الجارية تُجيب عن أسئلة مختلفة تمامًا، وأن إجبار دفتر واحد على القيام بالأمرين يجعل كلا الإجابتين غير موثوقتين.
افترضت أن «زدجر» سيتبنّى نموذجًا واحدًا. وتهاوت هذه الفرضية حين تعقّبتُ سبب أنه يجمع بينهما، وظيفةً وظيفة.
تُدرج مواد «دسك» خمسَة أشياء يدعمها «زدجر» تحديدًا: التسوية والاسترداد المتوافقان، ومنع المستخدمين المُسبقين بالموافقة من امتلاك أكثر من حساب واحد، وتوزيع الأرباح، والتصويت، وتحويلاتٍ محدودة بسقف. فصلتُ أي فئة ينتمي إليها كل مطلب فعلًا، وما إذا كان المصدر كافيًا بالتحديد ليُخبرنا. يبدو أن «تقييد الحساب الواحد» و«التحويلات المُقفّلة» يحتاجان إلى تحققٍ لحظي بأسلوب الحسابات — هل هذا المُالك المحدد تجاوز العتبة، الآن وبالفعل. أمّا «توزيع الأرباح» و«التصويت» فيحتاجان إلى تسجيلٍ منفصل وقابل للتدقيق لكل مركز/وضعية، أقرب إلى تتبّع الملاحظات الفردية على نمط UTXO.
يُستحسن أن أكون صريحًا: مواد «دسك» لا تُفصّل أي نموذج بعينه يتولى التسوية والاسترداد بشكل آلي. لن أُخمّن آلية ذلك فقط من أجل جعل القائمة تبدو مكتملة.
لا يغطي أيّ نموذج وحده الوظائف التي استطعت تأكيدها. فالنظام المُقتصر على الحسابات يواجه صعوبة في إثبات مركز/وضعيةٍ سابقة بعينها عند إجراء تدقيق أرباح. أما نظام UTXO المُقتصر فيواجه صعوبة في فرض حدّ لحظي دون فحص كل «ملاحظة» في الوقت نفسه.
الاختبار الحقيقي لـ DUSK هو ما إذا ظل هذا المزج قابلاً للصيانة مع قيام المزيد من المُصدِرين بضبط عتباتهم الخاصة عليه.
هل يؤدي الجمع بين نموذجين محاسبيين إلى حلّ احتياجين حقيقيين مزدوجين، أم أنه يستورد مجموعتين من حالات الحافة بدلًا من واحدة؟
تعتمد عمتـي على دفـترين منفصلين لسجلّات أعمالها العقارية المؤجرة — أحدهما لتتبّع أي وحدةٍ بعينها تابعة لأي مستأجر، والآخر لتتبّع إجمالي الإيجار المحصّل هذا الشهر. سألتُها لماذا لا تستخدم دفترًا واحدًا فقط. قالت إن الملكية الفردية والأرصدة الجارية تُجيب عن أسئلة مختلفة تمامًا، وأن إجبار دفتر واحد على القيام بالأمرين يجعل كلا الإجابتين غير موثوقتين.
افترضت أن «زدجر» سيتبنّى نموذجًا واحدًا. وتهاوت هذه الفرضية حين تعقّبتُ سبب أنه يجمع بينهما، وظيفةً وظيفة.
تُدرج مواد «دسك» خمسَة أشياء يدعمها «زدجر» تحديدًا: التسوية والاسترداد المتوافقان، ومنع المستخدمين المُسبقين بالموافقة من امتلاك أكثر من حساب واحد، وتوزيع الأرباح، والتصويت، وتحويلاتٍ محدودة بسقف. فصلتُ أي فئة ينتمي إليها كل مطلب فعلًا، وما إذا كان المصدر كافيًا بالتحديد ليُخبرنا. يبدو أن «تقييد الحساب الواحد» و«التحويلات المُقفّلة» يحتاجان إلى تحققٍ لحظي بأسلوب الحسابات — هل هذا المُالك المحدد تجاوز العتبة، الآن وبالفعل. أمّا «توزيع الأرباح» و«التصويت» فيحتاجان إلى تسجيلٍ منفصل وقابل للتدقيق لكل مركز/وضعية، أقرب إلى تتبّع الملاحظات الفردية على نمط UTXO.
يُستحسن أن أكون صريحًا: مواد «دسك» لا تُفصّل أي نموذج بعينه يتولى التسوية والاسترداد بشكل آلي. لن أُخمّن آلية ذلك فقط من أجل جعل القائمة تبدو مكتملة.
لا يغطي أيّ نموذج وحده الوظائف التي استطعت تأكيدها. فالنظام المُقتصر على الحسابات يواجه صعوبة في إثبات مركز/وضعيةٍ سابقة بعينها عند إجراء تدقيق أرباح. أما نظام UTXO المُقتصر فيواجه صعوبة في فرض حدّ لحظي دون فحص كل «ملاحظة» في الوقت نفسه.
الاختبار الحقيقي لـ DUSK هو ما إذا ظل هذا المزج قابلاً للصيانة مع قيام المزيد من المُصدِرين بضبط عتباتهم الخاصة عليه.
هل يؤدي الجمع بين نموذجين محاسبيين إلى حلّ احتياجين حقيقيين مزدوجين، أم أنه يستورد مجموعتين من حالات الحافة بدلًا من واحدة؟
إخلاء مسؤولية: يتضمن آراء جهات خارجية. لا تُعدّ نصيحة. يُمكن استخدام Binance AI دون أي ضمان. اطلع على الشروط والأحكام.