كل النشاط الاقتصادي مبني تاريخيا على الوسطاء. أي ، حتى المعاملة البسيطة بين الطرفين مصحوبة بمشاركة مختلف الوسطاء - البنوك ، البورصات ، غرف المقاصة ، إلخ. استبعاد الوسطاء من شأنه أن يجعل التفاعل أكثر كفاءة. فلماذا لا تحاول بناء بنية تحتية جديدة لا مركزية على أساس blockchain ، حيث يمكن للمشاركين في الصفقة العمل مباشرة؟ في هذا المنشور ، سنتحدث عن الطريقة التي بدأنا بها رحلتنا إلى مثل هذه البنية التحتية: لقد طورنا معاملات blockchain وأجرينا في النهاية repos - قرض من المال مضمون بالأوراق المالية.
سندات قصيرة الأجل
كانت أول معاملاتنا المالية خارج البورصة على blockchain هي إصدار سندات قصيرة الأجل لمشغل الهاتف المحمول MTS بمشاركة الإيداع الوطني للتسوية (NSD). هذا هو نوع من "البنك المركزي" لجميع الودائع. الودائع هي وسطاء للبنية التحتية يحتفظون بسجلات لأصحاب الأوراق المالية ويصدرونها.
في تلك الصفقة ، سجلت MTS ، من خلال استدعاء وظيفة العقد الذكي ، في blockchain تعبيرا عن إرادة لبيع الأوراق المالية إلى Sberbank ، وأكدت في blockchain اتفاقها مع شروط المعاملة. تم استلام الأوامر المضادة الموقعة من كلا الطرفين من قبل NSD ، والتي نفذتها في أنظمتها المحاسبية. بالإضافة إلى ذلك ، عرضت blockchain حسابات المشاركين في المعاملات في الأوراق المالية والمال.
في هذا المشروع ، اخترنا النظام الأساسي
Hyperledger Fabric 1.1 مفتوح المصدر ، المصمم لإنشاء حلول blockchain للمؤسسات مغلقة. السلاسل العامة غير مناسبة هنا ، لأننا نحتاج إلى ضمان خصوصية البيانات. واجهنا مثل هذه القيود في طيار التخصيم في Sberbank مع M. Video ، والذي تم تنفيذه على سلسلة Ethereum blockchain. في المقابل ، يتيح لك Hyperledger Fabric وضع جميع المشاركين في معاملة في قناة مخصصة ، حيث يمكنهم تبادل أي معلومات ضرورية ومعالجتها بعقود ذكية كاملة الميزات.
تم تحميل التعليمات البرمجية المصدر لمشروع إصدار سندات MTS بشكل عام على GitHub. بدون حتى الدخول في خوارزمية العمل ، يمكنك أن تفهم أنه في دورة حياة إحدى المعاملات ، تم إعطاء blockchain دورًا متواضعًا إلى حد ما كنقل لأوامر المقاصة. من ناحية أخرى ، على أساس هذه التعليمات ، تغيرت أرصدة الحسابات - لذلك من وجهة نظر منطق الأعمال ، كان هذا أكثر إثارة للاهتمام من خدمة إدارة المستندات الإلكترونية البسيطة.
والميزة الرئيسية للحل كانت براعة. يغطي مخطط "الطرفان المقابلان والمسجل" أي معاملة تقريبًا في سوق OTC ، ومع تغييرات طفيفة - معظم المعاملات التجارية بشكل عام.
REPO 1.0
في مشروع جديد على blockchain ، قررنا أن نظهر كيفية تنفيذ اتفاقية إعادة الشراء في نظام لامركزي - قرض من المال مقابل الأوراق المالية. عادةً ما تمر هذه المعاملات وغيرها من معاملات OTC عبر الوسطاء - الإيداع وغرف المقاصة والسماسرة.
في هذا المشروع ، دخلنا في اتفاقية إعادة شراء بين سبيربنك وشريك أجنبي. وقد استخدمت بالفعل Hyperledger Fabric الإصدار 1.2. مقارنة بسندات MTS ، كان لدينا اختلافان:
- تلقى مشاركان فقط في الصفقة مرتبطان بسلسلة المفاتيح ، والتي كانت ودائعها - Euroclear and Clearstream - جميع الطلبات عبر قنوات نقل البيانات التقليدية من المكاتب الخلفية لـ Sberbank والأطراف المقابلة لها.
- في العقد الذكي ، قمنا بتنفيذ منطق الأعمال المعقد: تم تنزيل عروض الأسعار اليومية للأوراق المالية التي كانت بمثابة ضمان للقرض إلى blockchain ، وحساب العقد الذكي الحاجة ومقدار السداد المبكر ، مع الأخذ في الاعتبار التكلفة المتغيرة للضمانات والخصم وتقويم بورصات الخروج وغيرها من المعالم. لا يمكن الحصول على تزامن P2P لخوارزميات الحساب بين المشاركين دون تسجيل موزع. هذا هو أكثر ملاءمة من حساب مستقل للالتزامات والمبالغ من جانب كل جانب - لا تسويات تستغرق وقتا طويلا ، لا تأكيدات.
نظمت بين الأطراف المقابلة دردشة وسير العمل داخل القناة. تم تخزين البيانات عليها في blockchain. بعد كل تغيير في السجل الموزع ، تلقى أعضاء القناة تنبيهًا بالبريد الإلكتروني.
"REPO 1.0" عملنا من الجانب القانوني. بمساعدة واحدة من مكتب محاماة كبير ، تم إجراء تحليل لقضايا المحكمة العليا في لندن. بالإضافة إلى ذلك ، استخدمت EDS للبنك ونظيره الآخر خوارزميات تشفير مختلفة.
كيف يعمل REPO 1.0؟
كل طرف في الصفقة لديه عقدة blockchain الخاصة به. جميع العقد متصلة ببعضها البعض في شبكة P2P. لنفترض أنك بحاجة إلى عقد صفقة. ننشر عقدًا ذكيًا بين أطراف الصفقة ، حيث يتم وصف الأداة المالية بالكامل.
بعد إنشاء العقد من جانبنا ، يتم توقيعه من قبل المتداول. يراجع العميل ويوقع العقد أيضًا. ثم تتم مراجعة التوقيعات والتحقق منها. في هذه الحالة ، تم إجراء المعاملة بموجب القانون الإنجليزي ، وتم إدخال البيانات الموجودة على التوقيع الرقمي الإلكتروني في مستند GMRA. للتوقيع من قبل العميل ، يلزم التحقق من وجود شخص مفوض في شهادة التوقيع. أخيرًا ، يقبل العميل العقد ويوافق على جميع الشروط. يمكنك إرفاق أي عدد من الوثائق في العقد الموقع.
بعد ذلك ، يحصل العقد على الحالة "في العمل". يتم إعادة حساب العقد "الجاري" تلقائيًا عند تحميل أسعار السوق الجديدة. إذا كان هناك ضمان في العقد ، يتم أخذ سعر السوق ، ويتم إعادة حساب القرض إلى القيمة (LTV) - نسبة مبلغ القرض إلى قيمة الأوراق المالية. LTV هي واحدة من المصطلحات الرئيسية في معاملة الريبو ، حيث يتم تحديد معناها في العقد. ارتفع سعر السهم بحدة - وأصبحت تقنية LTV أقل من السعر المذكور في GMRA (عندما يتعلق الأمر بالقانون الإنجليزي). وفقًا لذلك ، يعيد البنك الأوراق المالية إلى العميل (كواحد من الخيارات) ، حيث أنه مع الأخذ في الاعتبار الأسعار الجديدة ، اتضح أن البنك يتمتع بأمان أعلى.
ولكن إذا أصبح حجم LTV أكبر ، فإن البرنامج يسمح لك بطباعة إشعار ضمان - إخطار للعميل حول الحاجة إلى توفير أمان إضافي (الأسهم أو المال) بحيث تعود قيمة LTV إلى القيمة الأولية. في السابق ، كان لا يمكن إرسال إشعار إضافي إلا عن طريق البريد ، وتم إنشاء مستندات منفصلة لهذا الغرض ، وخلال إنشاء هذه المستندات ، يمكن أن يتغير LTV مرة أخرى. الآن نرى نفس الحسابات مع العميل عبر الإنترنت ، يمكننا التفاعل بسهولة.
بالإضافة إلى ذلك ، يقوم البرنامج كل يوم بتحديد سعر إعادة شراء الأوراق المالية ، مع مراعاة الفائدة. إذا كان العميل لا يوافق عليه عند تحميل سعر السوق ، فهو ينظر إلى سجل إعادة الحساب الكامل - ما هو ، وما أصبح ، وما هو السعر الذي تم تحميله ، ومن أين جاء. ثم تبدأ مناقشة الدردشة.
REPO 2.0
أردنا أن يكون REPO على blockchain قادراً على بدء حركة الأصول الحقيقية بناءً على منطقنا الداخلي. لكن في REPO 1.0 ، نظرًا لصعوبات تنظيمية في ربط المستودعات الغربية ، لم نتمكن بعد من تحقيق ذلك. لذلك بدأنا الإصدار التجريبي الجديد Repo 2.0. كان لديه هدفين:
- يجب أن تتم الصفقة بمشاركة طرفين والإيداع ، لتحقيق أقصى استفادة من البنية التحتية لمشروع السندات MTS.
- يجب تمكين blockchain لإعادة تقييم الضمان وإعداد مكالمة الهامش التي يمكن تنفيذها تلقائيًا بواسطة جهة إيداع متصلة بشبكة موزعة.
NSD على الفور أراد الاتصال بالمشروع. من أجل الحصول على صفقة بدأت في blockchain في المجال المحافظ للقوانين الفيدرالية التي تحكم السوق المالية المحلية ، عملنا مع محامين من أجل اتفاق تكميلي من خمس صفحات لاتفاقية إدارة الوثائق الإلكترونية. تم التوقيع عليه من قبل جميع الأطراف في الصفقة و NSD.
عملت NSD كغرفة مقاصة في هذه المعاملة. قام بتنفيذ جميع التعليمات حول حركة الأموال والأوراق المالية. تمت هذه الصفقة بموجب القانون الروسي.
قبل العميل العقد مع توقيع إلكتروني. بعد ذلك تم قبول الاتفاقية من قبل سبيربنك بتوقيعها - حيث تحقق من امتثال جميع المعلمات للقيم اللازمة وسلطة الشخص الذي قبل من العميل. بعد ذلك ، ذهب العقد إلى العمل. NSD تحميل بيانات السوق ، عقد ذكي إعادة حساب.
كيف يعمل REPO 2.0؟
لنشر الشبكة والتفاعل مع واجهة العميل برمز السلسلة ، استخدمنا حل
Fabric Starter . بدلاً من واجهة grpc القياسية لـ HLF ، توفر واجهة برمجة تطبيقات REST ، والتي في حالتنا قللت بدرجة كبيرة من تعقيد التكامل.
ارتفعت الشبكة على النحو التالي. أطلق كل جانب من الجوانب الثلاثة بعد التثبيت المسبق على خادم Docker ، Fabric Starter ، الذي أنشأ حاويات تحتوي على مكونات العقدة. تضمنت هذه المكونات نظيرًا خارجيًا للتفاعل مع المؤسسات الأخرى وخدمة API REST التي من خلالها تفاعلت العقدة مع تطبيق العميل. عند بدء تشغيل Starter ، تم أيضًا تكوين شبكة blockchain وإنشاء قناة خاصة تم فيها تثبيت رمز السلسلة مع سياسة المصادقة. في حالتنا ، يجب أن يكون لكل معاملة توقيعات المشاركين الثلاثة.
أثناء مرحلة الاختبار ، تم استخدام Docker Swarm لتنظيم اتصال خوادم المشاركين ، ولكن لغرض التوصل إلى صفقة حقيقية ، تحولوا إلى DNS. النظام الأساسي نفسه مسؤول عن نقل الرسائل ؛ يتم إرسال البيانات عبر الإنترنت باستخدام تشفير TLS.
الجانب الفني للقضية
تبدأ عملية تطوير تطبيق موزع على HLF بشكل تقليدي تمامًا - بهياكل البيانات ورمز السلسلة (في الواقع ، مجموعة من الإجراءات المخزنة) ، والتي تؤدي نداءها إلى تخزين هذه الهياكل أو تعديلها أو قراءتها من دفتر الأستاذ. يسمح النظام الأساسي باستخدام لغات البرمجة المختلفة لتطوير رموز السلسلة و DBMSs للتخزين المحلي. نحن نفضل الذهاب و CouchDB ، على التوالي.
الجوهر الرئيسي لمشاريع الريبو في نموذج البيانات لدينا هو العقد نفسه والتزاماته الفرعية. تم إنشاؤها لكل من الطيارين ، وكذلك لنداءات الهامش. كانت هذه البنية خطوة إلى الأمام مقارنةً بنموذج السندات MTS ، الذي استند إلى جوهر "الطلب". كما تم إنشاء كائنات مستقلة للأوراق المالية ، والتي تم ترميزها جزئيًا. لكن مع تطوير التجربة في إدارة الحساب والرمز الافتراضي للأموال ، قررنا تأجيل أحد الإصدارات التالية من الحل.
المهام الرئيسية لحلنا:
- إنشاء عقد.
- توقيع عقد مع EDS الخاص بك يؤكد قبول شروط العقد.
- قم بتنزيل أسعار السوق وابدأ في إعادة حساب قيمة الضمان. تسبب انحرافه عن الحد المحدد في إنشاء التزام بالهامش الجديد.
- تعكس حالة الالتزام.
على الجانب الفني ، يعتبر إجراء إعادة التقييم أكثر إثارة للاهتمام هنا. لنحللها بمزيد من التفاصيل.
في عملية الأعمال ، ينبغي إطلاق الإجراء مرة واحدة يوميًا ، بعد قيام Oracle (في الإصدار التجريبي من "REPO 2.0" الذي أجرته NSD) بتحميل عروض الأسعار المحدثة للأوراق المالية في النظام.
func (t *CIBContract) recalculationData(stub shim.ChaincodeStubInterface, loadData *loadDataType, curDay string) pb.Response {...}
تمر الدورة الرئيسية للإجراء بجميع الأوراق المالية التي تم تحديث عروض الأسعار لها.
for _, securities := range loadData.Securities {...}
بعد ذلك ، يتم إجراء العديد من الاختبارات. على سبيل المثال ، إذا كان التبادل الذي تم استلام بيانات السوق به اليوم يوم عطلة ، فلا ينبغي أن يحدث إعادة الحساب.
if t.checkHoliday(stub, contract.Settings.Calendars) == "yes" { hisYes := historyType{curDay, "LoadData. Calendar", "System", "LoadData. Today is holiday ! No load market data to contract !"} ... contract.History = append(contract.History, hisYes) … err = stub.PutState(contrID, contractJSONasBytes) }
لحساب سعر السند المحدّث ، تتم إضافة عائد القسيمة المستحقة (NDC) إلى صافي سعر التحميل. نفذ الطيار الدعم لخطة 30/360 لحساب NKD.
priceIzm = float64(securities.Price + float64(securities.CouponRate)*float64((int(settlementDate.Year()) - int(dateStart.Year()))*360 + (int(settlementDate.Month()) - int(dateStart.Month()))*30 + (int(settlementDate.Day()) - int(dateStart.Day())))*100/360/100) curCurrVal = priceIzm
إذا كانت عملة المعاملة مختلفة عن العملة التي يتم فيها نقل الورقة المالية ، يتم إجراء ترجمة الصرف.
if contract.GeneralTerms.PurchasePrice.Currency != securities.Currency { curCurrName = securities.Currency + "-" + contract.GeneralTerms.PurchasePrice.Currency for _, currency := range loadData.Currencies { if currency.Name == curCurrName { curCurrVal = priceIzm * currency.Value } } }
الآن نحن بحاجة لحساب LTV. الحفاظ على قيمة معامل القديم للقصة.
oldCurLTV := contract.MarginingTerms.CurrentLTV
من الضروري مراعاة مكالمات الهامش المنفذة خلال مدة المعاملة. يمكن أن تأتي المتطلبات من كلا الجانبين ، وفي شكلين:
- الأوراق المالية. يقوم المقترض بعمل تأمين إضافي في حالة انخفاض سعر السوق للأوراق المالية. يقوم الدائن بإرجاع جزء من الورقة المالية في حالة زيادة السعر.
- المال. يقوم المقترض قبل الموعد المحدد بسداد جزء القرض الذي توقف عن تغطيته بضمان أرخص. المقرض يزيد من مبلغ القرض استجابة لزيادة في قيمة الضمان.
في الحالة الأولى ، يتم ببساطة تحديث كمية الأوراق المالية في الضمان. وفي حالة جني الأموال منها ، من الضروري أيضًا تجميع الربحية المحددة في الشروط الإضافية للمعاملة.
for _, addCollateral := range contract.MarginingTerms.AddCollateral { currSumCollateral := addCollateral.Sum + (addCollateral.Sum*contract.MarginingTerms.RateOnCashMargin*float64(deltaColDate) / float64(contract.MarginingTerms.Basis))/100 ... allSumCollateral = allSumCollateral + currSumCollateral ... ht := historyType{curDay, System", "LoadData. Recalculation data(addCollateral) Contract " + contrID + " - currSumCollateral: " + strconv.FormatFloat(float64(currSumCollateral), 'f', 2, 64) ... } ... contract.History = append(contract.History, ht) }
نحن نحسب المبلغ الإجمالي لإعادة الشراء - في الواقع ، هذا هو مبلغ القرض مع الفائدة ، والتي نحتاج إلى سدادها.
rePurchasePriceCur := contract.GeneralTerms.PurchasePrice.Sum + (contract.GeneralTerms.PurchasePrice.Sum*contract.GeneralTerms.RepoRate*float64(deltaSigningDate)/float64(contract.MarginingTerms.Basis))/100
الآن نحن نحسب معامل LTV. للقيام بذلك ، قم بطرح الأوراق المالية النقدية من سعر إعادة الشراء وقسم القيمة الناتجة على إجمالي قيمة الأوراق المالية في الورقة المالية. يتم وضع علامة "-" على المبالغ المقيدة من قبل الدائن وسيتم إضافتها إلى سعر إعادة الشراء.
contract.MarginingTerms.CurrentLTV = (rePurchasePriceCur - allSumCollateral) * float64(100) / (float64(contract.GeneralTerms.PurchasedSecurities.Quantity) * curCurrVal)
أخيرًا ، نحسب المشغلات في العقد. سيقوم الإجراء نفسه بإنشاء كائنات ترتيب استدعاء الهامش إذا كانت قيمة LTV تنحرف عن الممر المحدد.
contract = t.checkTriggerEvents(stub, "LoadData", contract, curDay, securities)
واكتب المعلومات إلى السجل لعرضها على واجهة المستخدم.
ht := historyType{curDay, "System", "LoadData. Recalculation data(change curLTV, ADTV) Contract " + contrID + " - oldCurLTV: " + strconv.FormatFloat(float64(oldCurLTV), 'f', 2, 64) + ", newCurLTV: " + strconv.FormatFloat(float64(contract.MarginingTerms.CurrentLTV), 'f', 2, 64)...} contract.History = append(contract.History, ht)
لتلخيص
مثل هذا المخطط يمكن أن يعمل ليس فقط مع الأوراق المالية والعقود ، ولكن أيضا في السيناريوهات الأخرى. على سبيل المثال ، مع إمدادات الكهرباء ، حيث توجد تعريفات مختلفة ، وصلات مختلفة في أوقات مختلفة. أو مع العوملة - الإقراض للموردين عن طريق إشارات شحن البضائع. هناك العديد من حالات المستخدمين في الاقتصاد ، عندما يستخدم الجميع مصادر البيانات الخاصة بهم والتي يجب التحقق منها.
هدفنا هو إنشاء شبكة تربط البنوك مع بعضها البعض وعملائها على الصعيد الوطني ، واستخدام العقود الذكية لوصفها ليس عقود تشفير ، ولكن الاقتصاد التقليدي - الأدوات المالية. ستكون هذه الشبكة مستقرة ومفتوحة ، وكما يجب أن تكون في شبكة P2P ، فلن يكون لأحد هنا حالة خاصة.