قدمت سلسلة البلوك تشين ذات الطبقة 1 Tempo، التي طوّرتها Stripe وParadigm معًا، في 31 مايو اقتراح TIP-1061 بشأن حسابات التوقيع المتعدد الأصلية، بهدف إدخال التوقيع المتعدد باعتباره النوع الرئيسي للحسابات على مستوى البروتوكول في الشبكة، بما يتيح التحكم بالتوقيع المتعدد دون الحاجة إلى نشر محافظ عقود ذكية مثل Safe. يستهدف TIP-1061 حالات استخدام مثل المنظمات اللامركزية المستقلة DAO والجهات المؤسسية وعُقد التحقق، ولا يزال في مرحلة المسودة.
المواصفات التقنية المؤكدة
يتضمن التصميم الأساسي لـ TIP-1061 التفاصيل التقنية المؤكدة التالية. يُشتق عنوان حساب التوقيع المتعدد من تجزئة الإعداد الأولي (config_id)، وبعد أي تعديل لاحق لقائمة الأعضاء أو أوزان التوقيع أو العتبة (threshold)، يبقى عنوان الحساب كما هو.
تدعم أنواع التوقيع الثلاثة: Secp256k1 وP256 وWebAuthn. كما يدعم التوقيع المتعدد بنمط M-of-N (حيث weight = 1 لكل مالك) والتوقيع المتعدد المرجّح (تفويض غير متماثل)، مثل أن يتمكن مالك ذو وزن مرتفع (weight = 100) من التفويض منفردًا، أو يفوّض مالكان بوزن متوسط (كل منهما weight = 50) معًا. يسمح كل حساب توقيع متعدد بما يصل إلى 10 مالكين بحد أقصى (MAX_MULTISIG_OWNERS = 10).
قيود التصميم: عدم دعم AccountKeychain و EIP-7702
ينص TIP-1061 صراحةً على أن حسابات التوقيع المتعدد الأصلية لا تدعم الوصول إلى مفاتيح AccountKeychain؛ وإذا كان msg.sender حساب توقيع متعدد أصليًا، فيجب رفض أي استدعاء لمُعدِّل (modifier) AccountKeychain. وتتمثل حجة تصميم الاقتراح في ما يلي: السماح لمفتاح تفويض واحد بالاستدعاء بصفة حساب أب (parent account) سيحوّل مفتاحًا خاصًا أصليًا إلى قدرة دائمة تؤدي دور عنوان التوقيع المتعدد ضمن أي نطاق تفويض، وهو ما لا يتماشى مع مبدأ تصميم “الهوية الخاضعة لعدد مُحدّد قانونيًا من الأشخاص” (法定人數控制的身份).
علاوة على ذلك، لا يجوز تثبيت أكواد EVM bytecode أو أكواد تفويض EIP-7702 بعد مرحلة التمهيد (Bootstrap) لحسابات التوقيع المتعدد الأصلية.
حالة المسودة: أمور لم تُحسم بعد
يظل الاقتراح في مرحلة المسودة حتى الآن؛ ولا تزال خطة احتساب الغاز (الموسومة في المستند بـ “قائمة انتظار/مطلوب”) وعنوان عقد التوقيع المتعدد المُسبق التجميع (سيُخصص قبل الخروج من مرحلة المسودة) غير نهائية. كما ينص الاقتراح على أنه قبل بدء نفاذ TIP-1061، يجب رفض جميع المعاملات التي تتضمن TempoSignature::Multisig. ويجب أيضًا رفض جميع المعاملات التي تحمل حقل multisig_init قبل بدء نفاذ الاقتراح.
الأسئلة الشائعة
ما الفرق الجوهري بين التوقيع المتعدد الأصلي في TIP-1061 ومحافظ العقود مثل Safe؟
يرفع TIP-1061 التحقق من التوقيع المتعدد إلى مستوى البروتوكول؛ فلا يلزم نشر محافظ عقود مثل Safe على السلسلة لتحقيق قدرات التحكم المكافئة في العتبة. وهذا يلغي تكاليف نشر العقود، كما أن عنوان الحساب يظل ثابتًا بعد اشتقاقه من الإعداد الأولي، ولا يتغير مع تحديثات الأعضاء.
لماذا يمكن أن يبقى عنوان حسابات التوقيع المتعدد دون تغيير بعد تحديثات الأعضاء؟
يُشتق عنوان حساب التوقيع المتعدد من تجزئة config_id، ويُحسب config_id بناءً على مجموعة المالكين الأولية (بما في ذلك العناوين وأنواع التوقيع والأوزان) والعتبة. لا يتغير config_id خلال مدة بقاء الحساب. وتقوم استدعاءات updateMultisigConfig اللاحقة بتحديث التكوين المحفوظ حاليًا فقط، دون تغيير config_id نفسه أو عنوان الحساب المشتق.
ما أبرز حالات الاستخدام المستهدفة لـ TIP-1061؟
يشير قسم الدوافع في الاقتراح صراحةً إلى أن السيناريوهات المستهدفة هي للمستخدمين الذين يحتاجون إلى شرط ألا يستطيع أي مفتاح خاص منفرد نقل الأموال أو تعديل إعدادات التشغيل بشكل منفرد. وتشمل ذلك الفرق (Teams) والدوائر المالية (Treasury) وعُقد التحقق (Validators) ومشغلي الجهات المؤسسية (Institutional Operators).
