onchain lending protocols offer risk-differentiated products in theory. in practice most of them offer the same terms to everyone because they have no verifiable way to evaluate who someone actually is or what their financial position looks like.
the credit underwriting section of the Newton whitepaper describes a different model. lending parameters credit limits, interest rates,,,, collateral requirements determined by composable policy evaluation rather than centralized scoring or 0ne-size-fits-all collateralization ratios.
the mechanic is specific. the policy engine evaluates credentials credit history, income verification, collateral value and outputs a credit band that determines the terms available to the borrower.
the credentials are privacy-preserving. the lender sees the policy output this borrower qualifies for these terms without seeing the underlying financial data that produced that output... the borrower presents proof of their financial position without exposing the raw numbars to a public chain or to the lending protocol itself.
that combination verifiable credit evaluation with privacy-preserving inputs is what makes onchain lending actually risk-differentiated rather than just collateral-ratio differentiated. the difference between those two models is significant for borrowers who have real creditworthiness that the current onchain systm has no mechanism to recognize.
i find this one of the most practically impactful use cases in the Newton roadmap for regular DeFi users rather than just institutions.
whether credit credential issuers integrate fast enough to make this available at scale iss the adoption dependency worth watching??
جلست مع قسم إقرارات الامتثال الخاصة بورقة نيوتن البيضاء الليلة الماضية، وهذا أوضح شيئًا كنت أفكر فيه بشكل غير دقيق لفترة.@NewtonProtocol توجد تفرقة فئوية تهم كثيرًا في الامتثال التنظيمي، وقلّة جدًا في مجال السلسلة على الشبكة (onchain) من يبني عليها. التفرقة هي بين الأدلة على أن المراقبة تم تنفيذها، والأدلة على أن الإنفاذ/التنفيذ الفعلي قد حدث. يبدو هذان الشيئان متشابهين. لكنهما ليسا الشيء نفسه. تنتج منصة تحليل بيانات بلوك تشين سجلات. رصدت معاملة، وحسبت لها درجة مخاطر، ثم وصّفتها/علّمتها أو أزلت عنها الوسم، وسجلت أنها قامت بذلك. هذا السجل هو دليل على المراقبة. لكن المراقبة هي مراقبة/ترصّد، وليست إنفاذًا/تنفيذًا. نُفّذت المعاملة قبل إنتاج السجل. تم تحويل الأموال قبل أن يتصرف أي شخص استنادًا إلى الوسم. مُنظّم يطلب أدلة على أن نشاطًا غير مشروع....
لماذا تحتاج المؤسسات إلى سيولة عامة وتنفيذًا خاصًا في الوقت نفسه
كنت أراجع قسم التمويل اللامركزي المؤسسي في ورقة نيوتن البيضاء منذ صباح هذا اليوم، وهناك أطروحة مضمّنة فيها أعتقد أنها تستحق أن تُستخرج وتُفحَص بمعزل عن غيرها. أطروحتها هي كالتالي: يحتاج رأس المال المؤسسي إلى مسابح سيولة عامة لتحقيق العمق وقابلية التركيب، وإلى تنفيذ خاص تحكمه السياسات لضمان الامتثال والسرية. هاتان المتطلبان يسحبان في اتجاهين متعاكسين، وغالبية النهوج الحالية تجعل المؤسسات تختار واحدًا. إما أن تستخدم DeFi عامة وتقبل أن تدفق أوامرك مرئي للجميع، أو تستخدم بيئة مُصرَّحًا بها تمنحك الخصوصية لكن تقطعك عن عمق السيولة الذي يجعل DeFi العامة ذا قيمة....
شيء لم أكن أقدّره بخصوص $NEWT حتى قرأت كامل بنية بروتوكول نيوتن؛ وهو أن الرمز يرتبط بشكل مباشر بالوظيفة الفعلية للشبكة، بدل أن يكون مجرد مجاور لها.
الرَّمز يوفّر تشغيل بروتوكول نيوتن. هذا التأطير بسيط، لكن الآلية الكامنة محددة. يقوم المشغّلون بإيداع $NEWT -مجاور للأمن الاقتصادي عبر EigenLayer للمشاركة في تقييم السياسات. تتدفّق الرسوم من تقييمات السياسات إلى المشغّلين بنسبة إلى حصصهم ومشاركتهم. نموذج التسعير المعتمد على التنفيذ يعني...
يتم تعويض المشغّلين عن العمل الحاسوبي الفعلي: عدد تعليمات WASM، وعدد استدعاءات مزوّد البيانات، والـ bandwidth المستهلك أثناء التقييم، بدلًا من السعة المحجوزة التي قد تُستخدم أو لا تُستخدم.
هذا نموذج الرسوم مهم لمدى فائدة الرمز لأنه يربط إيرادات المشغّلين مباشرةً باستخدام الشبكة. كلما تكاملت المزيد من التطبيقات مع Newton وأرسلت المزيد من نوايا المعاملات لتقييم السياسات، تزداد تدفّقات رسوم المشغّلين. دور الرمز في...
طبقة الأمان الاقتصادي يعني أنه مع نمو الشبكة وزيادة قيمة الإقرارات/الشهادات الصحيحة، يجب أن تتوسع الحصة الداعمة لتلك الإقرارات وفقًا لذلك.
ودور الحوكمة يضيف طبقة أخرى. يشارك حاملو الرمز في عمليات الحوكمة التي تحدد معايير قبول المشغّلين، وشهادة/اعتماد وحدات السياسات، وجداول ترقية البروتوكول. هذه القرارات تؤثر مباشرةً على جودة وأمن الشبكة.
أجد أن تركيبة الأمان الاقتصادي وتوزيع الرسوم والحوكمة ذات معنى كهيكل منفعة للرمز. ليست مجرد زينة. لا تعمل الشبكة بدونها.
هل يولّد نموذج الرسوم إيرادات كافية للمشغّلين عند الحجم الحالي للشبكة لجذب والاحتفاظ بمجموعة مشغّلين عالية الجودة قبل أن تصل أحجام المعاملات إلى حدٍّ حرج؟ هذا سؤال التهيئة الذي يستحق المتابعة??
غالبًا ما يُقدَّم أمن السلاسل (onchain) على أنه مشكلة تدقيق/مراجعة لعقود ذكية. ابحث عن الأخطاء قبل النشر. اكتب تعليمات برمجية أفضل. تفترض الفكرة أن النظام يكون آمنًا إذا كان الرمز صحيحًا عند الإطلاق. لقد رأيت تلك الفكرة تفشل مرات كافية جعلتني أتوقف عن الوثوق بها. نموذج التهديد الذي يخرق البروتوكولات فعليًا على أرض الواقع مختلف. اختراق مفتاح الإدارة. أموال مسروقة تتحرك عبر DEXs والجسور قبل أن يتمكن أي شخص من الرد. هجمات الحوكمة حيث تُمال الأصوات في اللحظة الأخيرة بواسطة كبار حاملي الرموز الذين اشتروا مراكزهم تحديدًا للتأثير على النتيجة. هذه ليست أخطاء في الكود. إنها إخفاقات في الصلاحيات/التفويض. ينفَّذ الكود تمامًا كما كُتب. المشكلة هي أن ما كان مُصرَّحًا له بأن يفعله كان خاطئًا....
كنت أفكر في خارطة طريق نيوتن منذ أمس، وأن تسلسلها أكثر تدبّرًا مما يبدو للوهلة الأولى.
تُعدّ الـ vaults نقطة البداية. ليس لأنها أهم حالة استخدام على المدى الطويل، بل لأنها الأكثر ملموسية والأكثر قابلية للنشر فورًا. حزمة Newton Vault SDK تمنح منتجًا يعمل يمكن للمؤسسات تقييمه اليوم.
فهي تبني شبكة المشغّلين، وتختبر ضغطًا على محرك السياسة... وتُنتج إشهادات حية تُثبت أن النظام يعمل قبل التوسع إلى حالات استخدام أكثر تعقيدًا.
انطلاقًا من الـ vaults تمتد خارطة الطريق إلى RWAs والـ stablecoins ووكلاء الذكاء الاصطناعي، حيث يضيف كل واحد منها فئة جديدة من أنواع المعاملات ومتطلبات امتثال جديدة، بينما تتعامل البنية التحتية الأساسية نفسها مع ذلك. مجموعة الـ operator التي تتعلم تقييم سياسات مخاطر الـ vault تقوم أيضًا بتقييم قيود تحويلات الـ RWA وفحوصات عقوبات الـ stablecoin. محرك سياسة Rego نفسه الذي يتولى التعامل مع حدود السرعة (velocity limits) يتولى أيضًا أهلية المستثمرين وإسناد قاعدة السفر (Travel Rule attribution).
يجلس سوق Internet of Policies في نهاية هذا التطور. نظام بيئي قابل للتأليف (composable) حيث تُؤلف وحدات السياسة وتُنشر وتُعاد الاستفادة منها عبر التطبيقات بالطريقة نفسها التي تُبنَى بها مكونات البنية التحتية مفتوحة المصدر وتُشارك...
تُبنى وتُشارك. تُركّب التطبيقات مكدسات الامتثال من الوحدات المتاحة بدلًا من البدء من الصفر كل مرة.
أرى أن نهج vault-first منطقي فعلًا. ابْنِ المصداقية حيث تكون حالة الاستخدام أوضح، وأثبت أن البنية التحتية تعمل في ظروف حقيقية، ثم توسّع. البديل المتمثل في إطلاق النطاق الكامل دفعة واحدة هو ما يجعل بنية التفويض تفشل قبل أن تُستخدم.
سواء كان تطور رؤية Internet of Policies سيخلق نظامًا بيئيًا من مؤلفي السياسات العميقين بما يكفي لتغطية كامل طيف حالات الاستخدام المؤسسية هو سؤال طويل الأجل يستحق المتابعة؟؟
أريد أن أشرح شيئًا أعتقد أن معظم الناس يتجاهلونه تمامًا عندما ينظرون إلى بروتوكول نيوتن. وهو ما يحدث فعليًا عندما يوقّع المشغّل على نتيجة خاطئة. لأنه إذا لم تكن هناك عواقب حقيقية عند الخطأ، فإن النظام بأكمله ينهار. وقد اكتشف نيوتن هنا شيئًا ذكيًا بشكل مدهش. دعني أشرحها ببساطة. عندما يتم إرسال معاملة إلى نيوتن، يقوم المشغّلون بتقييمها وتوقيع النتيجة. ثم يتم تسجيل هذه النتيجة الموقّعة على السلسلة. وفي اللحظة التي تصل فيها، يبدأ مؤقّت. تفتح نافذة للتحدّي.
لقد تطرقت إلى قسم بنية التشغيل عبر السلاسل (cross-chain) في ورقة نيوتن البيضاء (whitepaper) أمس مساءً، وهذا هو الجزء الذي يحل سؤالاً كنت أحمله منذ قراءتي الأولى للنظرة العامة على البروتوكول. إذا كانت شبكة مشغلي نيوتن تعمل على إيثيريوم وتفوض المعاملات، فماذا يحدث عندما تُنفَّذ المعاملة على أربيتروم (Arbitrum) أو بوليغون (Polygon) أو بيز (Base)؟ هل تحتاج كل سلسلة وجهة إلى بنية امتثال خاصة بها؟ هل يحتاج المشغلون إلى التسجيل بشكل منفصل على كل سلسلة يرغبون في تقديم الخدمة لها؟ الإجابة هي لا على الاثنين، والآلية التي تجعل ذلك ممكنًا تستحق فهمها بعناية.
قائمة الشركاء المرفقة بإطلاق حزمة Newton Vault SDK فوجئت بها حقًا عندما راجعتها صباح اليوم. هذا ليس مجرد تجميع لأسماء لأغراض المظاهر. Chainalysis و Hexagate يتناولان..
مجالي الامتثال والأمان. تقدم Chainalysis بيانات العقوبات والبنية التحتية لمراقبة المعاملات التي تستخدمها المؤسسات المالية بالفعل ضمن مكدسات الامتثال الحالية. وتقدم Hexagate اكتشاف التهديدات في الوقت الفعلي، وهو مجال الأمان الذي يلتقط الاستغلالات النشطة والعناوين المخترَقة قبل أن تتفاعل مع الـ vault. وهما لاعبَان راسخان يغطيان مجالين من مجالات الإنفاذ الأربعة ببنية تحتية تعمل..
بالفعل على نطاق مؤسسي. تغطي Vaults.fyi مجال المخاطر ببيانات يستخدمها مشغلو الـ vault فعليًا لتقييم أداء الاستراتيجية وسلامة APY. وتقدم RedStone و Credora صحة الـ oracle وتقييم مخاطر الائتمان، وهي معلمات المخاطر المتبقية التي تحدد ما إذا كانت المعاملة آمنة بالنظر إلى ظروف السوق الحالية.
تأتي الطبقة الأمنية الكامنة وراء كل ذلك من EigenLayer للأمان الاقتصادي، و Succinct لتوليد إثباتات المعرفة الصفرية، و Rhinestone لبنية حسابات ذكية، و ، 0ctane لتجريد الغاز.
ما أعتبره مهمًا في هذا الجمع هو أن Newton لا يطلب من المؤسسات أن تثق بطبقة بيانات جديدة لاتخاذ قرارات حاسمة تتعلق بالامتثال. إنه يقوم بتوجيه البيانات عبر البنية التحتية التي تقوم تلك المؤسسات بتقييمها بالفعل، وتثق بها بالفعل، ولديها علاقات معها بالفعل، لكن يجعل مخرجات تلك البنية التحتية قابلة للإنفاذ على السلسلة بدلًا من كونها مجرد استشارية..
وهذا فرق ذو معنى في محادثة المبيعات داخل المؤسسات؟
مشكلة التوافق التي لا يتحدث عنها أحد في التفويض اللامركزي
هناك مشكلة تقنية مخبأة داخل تقييم السياسات اللامركزية لا تتم مناقشتها بالشكل الكافي، وقد استغرق مني وقتًا محرجًا طويلًا لأفهم بالكامل لماذا هذا الأمر مهم. عندما يقوم المشغّلون بشكل مستقل بجلب بيانات حساسة للوقت مثل أسعار الأصول وأي تحديثات لقوائم العقوبات وتغذيات الـ oracle، فقد يحصلون على قيم مختلفة من نفس المصدر اعتمادًا على اللحظة التي تصل فيها طلباتهم بالضبط. تُحدَّث قوائم العقوبات. تتحرك الأسعار بين أجزاء من الثانية. إذا حصل كل مشغّل على بيانات مختلفة قليلًا ثم حاول توقيع نتيجة سياسة باستخدام BLS، فلن تتطابق التواقيع لتتجمع. يتطلب تجميع BLS رسائل متطابقة.
لقد توقفت البيئة التنظيمية للأصول الرقمية عن كونها إرشادات استكشافية قبل مدة. ما الذي تغيّر مؤخرًا؟ أصبحت الأمور ملموسة بما يكفي بحيث لم يعد بإمكان المؤسسات تأجيل سؤال البنية التحتية بعد الآن.
قانون GENIUS أنشأ إطار ترخيص اتحاديًا مُلزمًا لمُصدري العملات المستقرة في الولايات المتحدة، مع متطلبات للاحتياطيات وحقوق الاسترداد وضوابط الامتثال.
أوجدت لائحة هونغ كونغ للعملات المستقرة نظام ترخيصًا موازًٍا يبدأ سريانه في أغسطس 2025. يغطي تنظيم MiCA في الاتحاد الأوروبي متطلبات مراقبة المعاملات وتقييم المخاطر والتحقق من الهوية عبر فئة مزودي خدمات الأصول المشفرة بأكملها. تتطلب إرشادات مجموعة العمل المالي (FATF) بشأن قاعدة السفر معلومات المُرسِل والمستفيد للمدفوعات التي تتجاوز الحدود المطبقة، مع تحديث الإرشادات لكونها تُعنى تحديدًا بالعملات المستقرة وDeFi.
ما تشترك فيه هذه الأطر هو توقع مشترك: ضوابط قابلة للتنفيذ على مستوى المعاملة نفسها، وليس مجرد فحوصات وقت التسجيل. أدلة تدقيق تُظهر تطبيق السياسات، وليس سجلات تُبيّن أن المراقبة كانت قيد التنفيذ.
هذا هو تحديدًا ما بُنيت عليه Newton كي تلبّيه. إفادات/إقرارات قابلة للتحقق بأن سياسةً محددة تم تقييمها لمعاملة محددة. إيصالات امتثال على السلسلة تعمل كدليل تدقيق. إنفاذ في لحظة تقديم المعاملة، بدلًا من المراقبة بعد أن تستقر.
فقط سوق العملات المستقرة وحده يقف عند 298 مليار دولار من المعروض الجاري، مع أكثر من 700 مليار دولار في حجم التحويلات الشهرية. المؤسسات التي تعمل بهذا الحجم باتت تعرف بالضبط إطار الامتثال الذي تحتاجه للالتزام. الجزء الناقص هو البنية التحتية للقيام بذلك بشكل يمكن التحقق منه.
Newton ليست سابقة على التنظيم. إنها تصل تمامًا عندما تبلورت هذه الأطر؟؟
كنت جالسًا مع قسم حل النزاعات في ورقة نيوتن البيضاء منذ أمس، وهذه هي الجزء الذي أعتقد أن معظم الأشخاص الذين يبنون على البروتوكول سيتعاملون معه كأمر مسلَّم به حتى يضطروا فعلًا إلى استخدامه، وعندها سيكون أهم شيء في النظام. الادعاء الأساسي الذي يقدمه نيوتن هو أن الإقرارات ليست في حاجة إلى الثقة. ليست تقليلاً من الثقة. بل هي بلا ثقة. هذا ادعاء قوي، ويتطلب آلية محددة لدعمه. نظام التحدي هو تلك الآلية. بعد تسجيل الإقرار على السلسلة (onchain)، تبدأ فترة نزاع يحددها الحوكمة. خلال هذه الفترة يكون الإقرار مؤقتًا؛ لا يمكن استخدامه لتفويض المعاملات. فقط بعد انتهاء النافذة دون وجود تحدٍ ناجح يصبح الإقرار نهائيًا. هذا يخلق فصلًا واضحًا بين حالتين غالبًا ما تتهاوى فيهما معظم الأنظمة إلى حالة واحدة.
لقد اطلعت على Magic Labs لأول مرة قبل يومين، وكان لتغيّر الخلفية أثر كبير في طريقة تفكيري تجاه مصداقية نيوتن كـبنية تحتية,,,,,
بنت Magic Labs محافظًا مضمنة. ليس كـتجربة، بل كبنية تحتية للإنتاج التي تعمل الآن كأساس تحت 57 مليون محفظة وتخدم أكثر من 200,000 مطوّر. إنها تُشغّل بنية المحافظ الخاصة بـ Polymarket. لقد دعمتهم PayPal Ventures. هذه هي مجموعة قامت بإصدار بنية تحتية للمحافظ على نطاق لا تصل إليه إلا فرق بروتوكولات كثيرة لا تتحدث عنه إلا في شرائح الخطط.
السبب الذي يجعل هذا مهمًا تحديدًا بالنسبة لنيوتن هو أن بنية التفويض لا تكون ذات مصداقية إلا بقدر الفريق الذي يستطيع بالفعل بناؤها وصيانتها. تتطلب طبقة بروتوكول مبتكرة تقع بين نية المعاملة وتنفيذ 0nchain خبرة تشغيلية عميقة في نوع البنية التحتية التي تلامس ملايين المستخدمين ولا تستطيع أن تفشل.
وتجربة المحفظة المضمّنة ذات صلة مباشرة. بناء أنظمة تعمل فيها إدارة المفاتيح غير الوصائية بشكل موثوق على مستوى المستهلك هو نفس فئة المشكلة المتمثلة في بناء أنظمة تعمل فيها معالجة السياسات بشكل موثوق على مستوى المعاملات. أنماط الفشل مختلفة، لكن الانضباط التشغيلي المطلوب هو نفسه...
أجد أن هذه الخلفية مطمئنة حقًا في مجال تُعد فيه مصداقية المطور الأساسي شيئًا يجب فحصه قبل الثقة بأي بنية تحتية جديدة في أي شيء ذي أهمية...
سواء كان الفريق سيوسّع شبكة مشغلي نيوتن بنفس الصرامة التشغيلية التي طبقوها على بنية المحافظ هو ما أريد أن أرى حدوثه خلال الأشهر الاثني عشر القادمة??
يشعر التنفيذ المدفوع بالسياسات بأنه أقل شبيهاً بميزة أخرى ضمن البلوك تشين وأكثر بوصفه بنية تحتية مفقودة للأتمتة الموثوقة. إذا كانت التطبيقات تحتاج باستمرار إلى قواعد قابلة للإنفاذ، فقد تصبح هذه الطبقة ضرورية بقدر أهمية العقود الذكية نفسها.
Python_Trading
·
--
يبدو أن كل سلسلة بلوك تشين تحاول حل جزء مختلف من لغز ما. فبعضها يركز على الأمان، وبعضها الآخر على قابلية البرمجة، وبعضها على السرعة. لكنني كنت أتساءل عمّا إذا كانت الطبقة المهمة التالية ليست عن تنفيذ أسرع على الإطلاق.
ربما يتعلق الأمر بضمان حدوث المعاملات للأسباب الصحيحة.
في الواقع، معظم المستخدمين لا يهتمون بإرسال معاملة. إنهم يهتمون بالنتيجة. يريدون إجراءات تتبع شروطاً وحدوداً وصلاحيات دون الحاجة إلى الوثوق بكل تطبيق على حدة كي يطبّق هذه القواعد بشكل صحيح. هنا يبدأ اهتمام التنفيذ المُدار بالسياسات بالظهور.
ما يلفت انتباهي هو أن هذه المقاربة ليست تنافس السلاسل القائمة فعلياً. إنها تضيف طبقة أخرى قد تجعل النشاط على السلسلة أكثر قابلية للتنبؤ وأكثر أماناً إذا ما تم تبنيها على نطاق واسع.
وأظن أيضاً أن الناس يُبالغون في تقدير مقاومة المطورين. غالباً ما يتبنى المطورون أدوات أفضل عندما تكون الفوائد واضحة. السؤال الأكبر هو ما إذا كان المستخدمون والتطبيقات فعلاً يحتاجون إلى هذه الإمكانية بدرجة كافية لجعلها معياراً.
البنية التحتية الجيدة وحدها نادراً ما تكسب. يجب أن تحل مشكلة حقيقية يشعر بها الناس يومياً؛ وإلا فقد تواجه حتى الأفكار الذكية صعوبة في اكتساب الزخم.
الإقرار المُوقَّع هو ما يحوّل الامتثال من مجرد وعد إلى دليلٍ يمكن التحقق منه ويمكّن أي شخص من تدقيقه. إن وجود الدليل، لا مجرد التطبيق، هو ما يمنح طبقة التفويض لدى نيوتن مصداقيةً طويلة الأمد.
BLANK Bro
·
--
صاعد
في البداية، افترضتُ أنه مجرد تأخير في الشبكة عندما شاهدتُ معاملةً تبقى معلّقةً لبرهة أطول مما هو متوقع قبل أن تُسوى. لم يكن الأمر كذلك. يدرج Newton فحصًا للسياسة داخل تلك الفجوة، وهي لحظة تقرأ فيها شبكة من المشغّلين القواعد التي كتبها المطوّر، وتتحقق منها مقابل إشارات على السلسلة وخارجها، ثم تقرر ما إذا كانت المعاملة تستحق الحق في الاستمرار. ما لفت انتباهي لم يكن الفحص نفسه. بل كان الإيصال. فكل تقييم، سواء تمت الموافقة عليه أو حُجب، يُكتب على السلسلة كتأكيد موقّع، وهو سجل دائم لكل «لا» بجوار كل «نعم»، ويمكن لأي شخص يكلّف نفسه عناء النظر التحقق منه. معظم المستخدمين لن يفتحوا أبدًا Newton Explorer. الإيصال ليس لهم. إنه للمراجع، والمخصّص، والمنظّم الذي لا يحتاج أبدًا إلى أخذ كلمة المنصة على محمل الثقة. وهذا يطرح السؤال الحقيقي: هل المطلوب هنا امتثال أسرع، أم أن يضع شخص آخر أخيرًا يده على الدليل. @NewtonProtocol $NEWT #Newt
لقد فوجئت حقًا بمجالات الإنفاذ الأربعة في حزمة Newton Vault SDK عندما رسمتها هذا الصباح؛ فهي تغطي نطاقًا أوسع مما يوحي به العنوان.
الامتثال هو الواضح. فحص OFAC، والتحقق من العقوبات، والطبقة التنظيمية التي تحتاج كل مؤسسة لإثباتها. وتقف الهوية جنبًا إلى جنب مع ذلك عبر التحقق والأهلية، للتأكد من أن الأطراف الصحيحة تتفاعل مع البروتوكولات الصحيحة. هذان المجالان وحدهما سيكونان منتجًا مفيدًا.
الأمان هو ما يجعل الأمر أكثر إثارة للاهتمام. حجب التهديدات في الوقت الفعلي. نوع الحماية التي لا تكتفي فقط بالتحقق من هويتك، بل تراقب ما يحدث للبروتوكول لحظة تنفيذ المعاملة، وتضع علامة على الأموال الواردة من عناوين مخترَقة، وتمنع التفاعل مع العقود المدرجة في القوائم السوداء، وتلتقط توقيعات الاستغلالات المعروفة قبل أن تُنفَّذ.
والمجال الرابع هو المخاطر.
مخاطر الطرف المقابل، سلامة APY، حدود الرافعة، صحة الـ Oracle. هذه المعلمات هي التي تحدد ما إذا كانت المعاملة آمنة للتنفيذ في ظل ظروف السوق الحالية، وليس فقط ما إذا كانت الأطراف المعنية ملتزمة....$LAB
ما لفتني في هذا التأطير هو أن معظم الأنظمة تتعامل مع مجال واحد أو اثنين فقط من هذه المجالات، وتعتبر الباقي مشكلة طرف آخر. إن حزم المجالات الأربعة كلها في طبقة إنفاذ واحدة على السلسلة يعني أن الـ vault الذي ينشر Newton يحصل على الصورة الكاملة في اللحظة التي تُقدَّم فيها المعاملة، بدلًا من تجميعها من أربعة مصادر منفصلة بعد وقوع ذلك.
ما إذا كانت المجالات الأربعة في طبقة واحدة ستظل متماسكة مع نمو تعقيد السياسات داخل كل مجال—سؤال التصميم الذي يستحق المتابعة??
الجزء من نيوتن الذي أعتقد أن المطورين سيفهمونه أسرع هو الجزء الذي سيفهمه مسؤولو الامتثال المؤسسي أبطأ، والعكس صحيح. Rego هي المكان الذي يلتقي فيه عالمان، وخيار التصميم لاستخدامها يستحق اهتمامًا أكبر مما يحصل عليه عادةً. Rego هي لغة السياسات من مشروع 0pen Policy Agent. تُستخدم على نطاق واسع في البنية التحتية للمؤسسات، مثل التحكم في قبول Kubernetes، وتفويض بوابة API، وسياسات خطوط أنابيب CI/CD. إذا كنت قد عملت في بنية تحتية حديثة للسحابة وبأي مقياس جاد، فمن المرجح جدًا أنك قد كتبت أو قيّمت سياسات Rego. إنها لغة تصريحية، ومُحسّنة بالأدوات بشكل جيد، ومرّست ومجرّبة في المعركة عبر نظام بيئي كبير قائم بالفعل.
عدت هذا الصباح عبر قسم RWA في ورقة نيون البيضاء، ونموذج التهديد الذي يبنون له أكثر تحديدًا مما كنت أتوقع. الأوراق المالية المُرمَّزة (tokenized) والعقارات ومنتجات الائتمان تحمل ثلاث أسطح هجوم متميزة لا يمكن للعقود الذكية القياسية معالجتها/
اختراق مفتاح المدير (admin key): المهاجم الذي يسيطر على المفتاح يتجاوز جميع ضوابط الوصول بالكامل. تلاعب الـNAV وبيانات الـoracle: يؤدي إلى تسعير غير دقيق للأصول لتمكين عمليات الاسترداد غير المصرح بها أو إصدار (minting) مُبالغ فيه. تغييرات الحالة غير المصرح بها: إصدار دون إذن، وتعديل قيود التحويل أثناء التنفيذ (mid-stream).
ما يقدمه نيون لبروتوكولات RWA هو مجموعة من قيود السياسات تعمل كـ "ثوابت تشغيلية" (runtime invariants). هذه ليست قواعد يمكن الالتفاف عليها إذا حصل شخص ما على مفتاح المدير.... بل يتم فرضها على مستوى المعاملة عبر متطلبات التوثيق (attestation). حواجز Mint وRedeem تضمن مشاركة المستثمرين المؤهلين فقط. تحقق سلامة NAV: يتحقق من أسعار الـoracle مقابل حدود التسامح (tolerance bounds). ضوابط التحويل: تقيّد نشاط السوق الثانوية على الأطراف المؤهلة....
الفكرة التي علقت بذهني هي أن هذه السياسات تعمل كقيود لا يمكن تجاوزها بغض النظر عن من يحمل مفتاح المدير. بالنسبة للمؤسسات التي تُحوِّل الأصول الحقيقية إلى رموز على سلاسل بلوكشين عامة، فإن مخاطر مفتاح المدير هي واحدة من أصعب المشكلات لحلّها. تحويل مخاطر مفتاح واحد إلى تفويض موزع عبر فرض السياسات هو إجابة مختلفة بنيويًا عن تلك المشكلة,,,
أجد أن هذه هي أكثر حالة استخدام مقنعة لاقتناع المؤسسات (institutional adoption). ليس لأن الخيارات الأخرى غير حقيقية. بل لأن البديل لبروتوكولات RWA في الوقت الحالي هو قبول مخاطر مفتاح المدير كتعرض معروف. سواء ستتطلب المؤسسات التي تُرمّز الأصول هذا المستوى من فرض التنفيذ على السلسلة (onchain enforcement) قبل أن تنشره أو ستتعامل معه كبنية تحتية اختيارية، هو سؤال يستحق المتابعة؟؟
ماذا يعني ذلك فعليًا بالنسبة للبلوك تشين ألا يرى بياناتك
كنت أمرّ من خلال بنية الخصوصية الخاصة بنيوتن منذ بعد ظهر أمس، وهذه هي الجزء من الورقة البيضاء الذي تطلّب أكبر قدر من إعادة القراءة كي أفهمه فعليًا. ليس لأن شرحه ضعيف. بل لأن التصميم مُتَطبّق/متدرّج بشكل حقيقي بطريقة تستغرق وقتًا كي يتم استيعابها بالكامل. الادعاءُ الأساسي هو أن البيانات الحساسة لا تُعرَض أبدًا على البلوك تشين. البلوك تشين يرى إثباتات وإقرارات فحسب، وليس بيانات الهوية الأساسية. هذه الادعاء يحتاج إلى أن يُدعَم بآليةٍ تقنية محددة، وإلا فهو مجرد لغة تسويقية. غلاف خصوصية نيوتن هو تلك الآلية.