كنت أقرأ عن نيوتن بنفس السؤال الذي أطرحه عادةً لأدوات الخزنة.
ليس ما الذي يمكنهم فعله.
كم جزء من سير العمل القديم يحتفظون به؟
هنا بدأت VaultKit تبدو مختلفة بالنسبة لي.
تصف الوثائق مجموعة أدوات TypeScript وعقود Solidity مرافقة، لكن الجزء الذي بقي معي كان أصغر من ذلك. يمكن للقيّم الاستمرار في استخدام سير عمل الخزنة الذي يعرفه بالفعل، بينما يتم تغليف كل إجراء بنسخة Shield وإرساله عبر إثبات امتثال (attestation) لسياسة نيوتن قبل أن تتلقى الخزنة المكالمة.
هذا نوع تصميم محدد جدًا.
لا يحاول جعل إدارة الخزنة تبدو جديدة لمجرد ذلك. بل يحاول جعل الأمر أصعب كي يتم تنفيذه بشكل خاطئ دون إجبار الفرق على إعادة بناء كامل نظامها.
أعتقد أن هذا هو التوتر الحقيقي هنا.
في خزائن DeFi، خصوصًا عندما يكون رأس المال المؤسسي حاضرًا، المشكلة نادرًا ما تكون مجرد القاعدة المكتوبة على الورق. الجزء الأصعب هو التأكد من أن القاعدة تُطبَّق فعلًا في كل مرة تتحرك فيها الخزنة. نيوتن يحاول نقل الوعد من القيّم إلى مسار التنفيذ نفسه.
لهذا السبب تهم سير العمل كثيرًا.
يستخدم النظام نسخًا حتمية لكل قيّم عبر ShieldFactory، ونيوتن يقول إن طبقة السياسة تعمل في شبكة mainnet في نسخة بيتا. لذلك فهذه ليست مجرد فكرة جميلة تجلس في منشور مدونة. إنها سير عمل مبني حول بوابة تقع قبل أن تتصرف الخزنة.
لكن ما زال هناك مقايضة.
تقليل الاحتكاك جيد فقط إذا كان المديرون يثقون بمسار الإثبات (attestation) ثقة كافية لاستخدامه. إذا بدا سير العمل مرهقًا، أو شعرت البوابة بأنها عبء إضافي، فسيميل الناس إلى البقاء بما يعرفونه بالفعل.
هذه هي النقطة التي سأراقبها.
ليس ما إذا كان الامتثال لخزائن DeFi يبدو جيدًا.
بل ما إذا كانت VaultKit تجعل الامتثال يبدو كترقية لسير العمل بدلًا من كونه ضريبة عليه.
هذه هي الطريقة الأكثر وضوحًا التي أستطيع بها قراءة نيوتن هنا. السؤال ليس ما إذا كان على مديري الخزائن أن تكون لديهم قواعد. السؤال هو ما إذا كانت القواعد يمكن أن تعيش داخل نفس سير العمل الذي يستخدمونه بالفعل، دون تحويل كل حركة إلى عملية جديدة ليتعاملوا معها ويتغلبوا عليها.
@NewtonProtocol #newt $NEWT
ليس ما الذي يمكنهم فعله.
كم جزء من سير العمل القديم يحتفظون به؟
هنا بدأت VaultKit تبدو مختلفة بالنسبة لي.
تصف الوثائق مجموعة أدوات TypeScript وعقود Solidity مرافقة، لكن الجزء الذي بقي معي كان أصغر من ذلك. يمكن للقيّم الاستمرار في استخدام سير عمل الخزنة الذي يعرفه بالفعل، بينما يتم تغليف كل إجراء بنسخة Shield وإرساله عبر إثبات امتثال (attestation) لسياسة نيوتن قبل أن تتلقى الخزنة المكالمة.
هذا نوع تصميم محدد جدًا.
لا يحاول جعل إدارة الخزنة تبدو جديدة لمجرد ذلك. بل يحاول جعل الأمر أصعب كي يتم تنفيذه بشكل خاطئ دون إجبار الفرق على إعادة بناء كامل نظامها.
أعتقد أن هذا هو التوتر الحقيقي هنا.
في خزائن DeFi، خصوصًا عندما يكون رأس المال المؤسسي حاضرًا، المشكلة نادرًا ما تكون مجرد القاعدة المكتوبة على الورق. الجزء الأصعب هو التأكد من أن القاعدة تُطبَّق فعلًا في كل مرة تتحرك فيها الخزنة. نيوتن يحاول نقل الوعد من القيّم إلى مسار التنفيذ نفسه.
لهذا السبب تهم سير العمل كثيرًا.
يستخدم النظام نسخًا حتمية لكل قيّم عبر ShieldFactory، ونيوتن يقول إن طبقة السياسة تعمل في شبكة mainnet في نسخة بيتا. لذلك فهذه ليست مجرد فكرة جميلة تجلس في منشور مدونة. إنها سير عمل مبني حول بوابة تقع قبل أن تتصرف الخزنة.
لكن ما زال هناك مقايضة.
تقليل الاحتكاك جيد فقط إذا كان المديرون يثقون بمسار الإثبات (attestation) ثقة كافية لاستخدامه. إذا بدا سير العمل مرهقًا، أو شعرت البوابة بأنها عبء إضافي، فسيميل الناس إلى البقاء بما يعرفونه بالفعل.
هذه هي النقطة التي سأراقبها.
ليس ما إذا كان الامتثال لخزائن DeFi يبدو جيدًا.
بل ما إذا كانت VaultKit تجعل الامتثال يبدو كترقية لسير العمل بدلًا من كونه ضريبة عليه.
هذه هي الطريقة الأكثر وضوحًا التي أستطيع بها قراءة نيوتن هنا. السؤال ليس ما إذا كان على مديري الخزائن أن تكون لديهم قواعد. السؤال هو ما إذا كانت القواعد يمكن أن تعيش داخل نفس سير العمل الذي يستخدمونه بالفعل، دون تحويل كل حركة إلى عملية جديدة ليتعاملوا معها ويتغلبوا عليها.
@NewtonProtocol #newt $NEWT