EIP-7805: फोर्क-चॉईसद्वारे लागू केलेल्या समावेश सूची (FOCIL)

Ethereum Cat Herders द्वारे PEEPanEIP चा भाग 141. होस्ट पूजा रंजन यांच्यासोबत इथेरियम फाउंडेशनमधील रोबस्ट इन्सेंटिव्ह्ज ग्रुपचे संशोधक आणि EIP-7805 (नवीन टॅबमध्ये उघडते) चे सह-लेखक थॉमस थियरी आणि ज्युलियन मा जोडले गेले आहेत. ते फोर्क-चॉईस एन्फोर्स्ड इन्क्लूजन लिस्ट्स (FOCIL) स्पष्ट करतात: इथेरियमला प्रोटोकॉल-स्तरावरील सेन्सॉरशिप प्रतिकाराची आवश्यकता का आहे, ही यंत्रणा कशी कार्य करते आणि अंमलबजावणीची सद्यस्थिती काय आहे.

ही ट्रान्सक्रिप्ट Ethereum Cat Herders द्वारे प्रकाशित केलेल्या मूळ व्हिडिओ ट्रान्सक्रिप्टची (नवीन टॅबमध्ये उघडते) एक सुलभ प्रत आहे. वाचनीयतेसाठी यात थोडे संपादन केले आहे.

परिचय (0:35)

पूजा रंजन: नमस्कार आणि PEEPanEIP मध्ये आपले स्वागत आहे, हा एकमेव शो आहे जिथे आम्ही इथेरियम सुधारणा प्रस्तावांचा (Ethereum Improvement Proposals) सविस्तर अभ्यास करतो आणि इकोसिस्टमवरील त्यांच्या प्रभावाचा शोध घेतो. हा भाग 141 आहे, जो Ethereum Cat Herders ने तुमच्यासाठी आणला आहे. मी तुमची होस्ट, पूजा रंजन आहे, आणि आज आपण EIP-7805, फोर्क-चॉईस एन्फोर्स्ड इन्क्लूजन लिस्ट्स (Fork-choice enforced Inclusion Lists) बद्दल बोलत आहोत.

नोव्हेंबर 2024 मध्ये दस्तऐवजीकरण केलेला, EIP-7805 हा एक स्टँडर्ड्स ट्रॅक कोअर प्रस्ताव आहे जो सध्या मसुदा स्थितीत आहे. या प्रस्तावाचे उद्दिष्ट प्रमाणकांच्या समितीला प्रत्येक ब्लॉकमध्ये व्यवहारांचा एक संच सक्तीने समाविष्ट करण्याची परवानगी देणे हे आहे. थॉमस थियरी, फ्रान्सिस्को डी'अमाटो, ज्युलियन मा, बर्नाबे मोनोट, टेरेन्स त्साओ, जेकब कॉफमन आणि जिहून सॉन्ग यांनी सह-लेखन केलेला हा प्रस्ताव भविष्यातील अपग्रेडसाठी सक्रिय चर्चेत आहे.

या भागात, आम्ही EIP-7805 चे तपशील, त्याचे परिणाम आणि इथेरियम इकोसिस्टमवरील त्याचा संभाव्य प्रभाव शोधू. या प्रस्तावाबद्दल अधिक बोलण्यासाठी, थॉमस थियरी आणि ज्युलियन मा आपल्यासोबत जोडले गेले आहेत. PEEPanEIP मध्ये आपले स्वागत आहे.

थॉमस थियरी: आम्हाला आमंत्रित केल्याबद्दल धन्यवाद.

ज्युलियन मा: होय, आम्हाला आमंत्रित केल्याबद्दल खूप खूप धन्यवाद.

पूजा रंजन: प्रस्तावाचा आढावा, तो आज कुठे उभा आहे आणि आपण तो इथरियम मेननेटवर किती लवकर पाहू शकतो हे जाणून घेण्यासाठी आम्ही उत्सुक आहोत. पण आपण सुरुवात करण्यापूर्वी, आमच्या समुदायाला या कामामागील संशोधक आणि विकासकांना जाणून घ्यायला आवडते. तुम्ही तुमच्याबद्दल, तुम्ही सध्या सहभागी असलेल्या प्रकल्पाबद्दल आणि इथेरियम इकोसिस्टममधील तुमच्या प्रवासाबद्दल थोडे सांगू शकाल का?

पाहुण्यांचा परिचय (2:14)

ज्युलियन मा: नक्कीच, मी सुरुवात करू शकतो. मी ज्युलियन आहे, थॉमसप्रमाणेच इथेरियम फाउंडेशनमधील रोबस्ट इन्सेंटिव्ह्ज ग्रुपमध्ये (Robust Incentives Group) संशोधक आहे. रोबस्ट इन्सेंटिव्ह्ज ग्रुप प्रामुख्याने प्रोटोकॉलच्या अर्थशास्त्रावर विस्तृतपणे काम करतो. आमच्यापैकी काही जण EIP-1559 सारख्या व्यवहार शुल्क यंत्रणांचा अभ्यास करत आहेत, तर इतर काही जण सहमती स्तर हल्ल्यांवर लक्ष ठेवून आहेत, जे बहुतांश आर्थिक फायद्यांनी प्रेरित असतात.

माझ्याबद्दल सांगायचे तर, मी पायाभूत शुल्क डेरिव्हेटिव्ह्जचा अभ्यास करण्यासाठी इंटर्नशिपपासून सुरुवात केली आणि त्यानंतर मी पूर्णवेळ रुजू झालो. मी प्रामुख्याने प्रस्तावक-निर्माता विभाजन (PBS) आणि MEV-संबंधित विषयांवर काम करत आहे, आणि आता मी या EIP सह FOCIL द्वारे समावेशन सूचींवर (inclusion lists) लक्ष केंद्रित करत आहे, तसेच अटेस्टेर-प्रस्तावक विभाजनाची (attester-proposer separation) वाट पाहत आहे. मी म्हणेन की अधिक सैद्धांतिक कामापासून सुरुवात करून ते एका EIP कडे नेण्याच्या या प्रक्रियेद्वारे संशोधनाला प्रत्यक्ष वापरात आणण्यासाठी मी सर्वात जास्त उत्सुक आहे, जेणेकरून ते इथेरियममध्ये प्रस्तावित आणि लागू केले जाऊ शकेल.

थॉमस थियरी: मी थॉमस आहे. मी देखील इथेरियम फाउंडेशनमध्ये रोबस्ट इन्सेंटिव्ह्ज ग्रुपमध्ये संशोधन करण्याचे काम करतो. माझी पार्श्वभूमी प्रत्यक्षात न्यूरोसायन्समधील पीएचडीची आहे, जी खूप वेगळी होती. पण मला ब्लॉकचेन आणि वितरित प्रणालींबद्दल (distributed systems) उत्सुकता निर्माण झाली, काहीतरी वेगळे करून पाहायचे होते, आणि मी ड्यून (Dune) नावाच्या एका क्रिप्टो डेटा कंपनीत रुजू झालो. मी तिथे काही काळ राहिलो, पण नंतर मला संशोधनाची उणीव भासू लागली, आणि मी सुदैवी होतो की मला EF (इथेरियम फाउंडेशन) आणि रोबस्ट इन्सेंटिव्ह्ज ग्रुपमध्ये सामील होण्याची संधी मिळाली, जो आतापर्यंतचा एक उत्तम अनुभव राहिला आहे.

मी अशाच विषयांवर काम केले आहे. मी रुजू झालो तेव्हा MEV हा खूप मोठा विषय होता. विशेष म्हणजे, माझ्या अगदी सुरुवातीच्या संशोधन पोस्ट खूप लहान होत्या, परंतु त्या समावेशन विलंब (inclusion delays) आणि सेन्सॉरशिप प्रतिकारावर (censorship resistance) होत्या. अलीकडच्या काळापर्यंत मी त्यात फारसा सखोल अभ्यास केला नव्हता. गेल्या सहा महिन्यांपासून ते एका वर्षापर्यंत मी सेन्सॉरशिप प्रतिकार आणि समावेशनाच्या बाजूने अधिक सक्रिय आहे. संशोधन कल्पनांपासून सुरुवात करणे, मागील कल्पनांमध्ये सुधारणा करणे ज्या खूप मनोरंजक होत्या परंतु ज्यामध्ये आपण चर्चा करणार आहोत त्यातील काही तपशील समाविष्ट नव्हते, एक प्रस्ताव तयार करणे, आणि आता अंमलबजावणी आणि डेव्हनेट असणे हे खरोखरच छान आहे, ज्याबद्दल मी बोललेल्या बहुतांश लोकांना वाटते की ही इथेरियमसाठी एक चांगली भर असेल.

पूजा रंजन: माहिती शेअर केल्याबद्दल धन्यवाद. डेव्हलपर्सची पार्श्वभूमी जाणून घेणे नेहमीच प्रेरणादायी असते. ते वेगवेगळ्या क्षेत्रांतून येत आहेत आणि शेवटी इथेरियम परिसंस्थेत योगदान देत आहेत हे पाहणे मनोरंजक आहे. मला समजले आहे की आज आपल्याकडे येथे एक सादरीकरण आहे. तर अधिक वेळ न दवडता, आपण त्यात डोकावूया.

सादरीकरण: FOCIL ची उद्दिष्टे (5:16)

ज्युलियन मा: उत्तम, खूप खूप धन्यवाद. EIP-7805, किंवा FOCIL, कसे कार्य करते आणि आपल्याला ते नेमके का करायचे आहे याबद्दल एका छोट्या सादरीकरणाने मी सुरुवात करू इच्छितो. याचा उद्देश संवादाला सुरुवात करणे हा आहे, त्यामुळे ते फार सखोल नसेल, जेणेकरून नंतर चर्चेसाठी थोडा वाव राहील.

इथेरियमची विश्वासार्ह तटस्थता वाढवणे हे FOCIL चे मुख्य उद्दिष्ट आहे. सध्या एका स्लॉटमध्ये एकाच प्रस्तावक किंवा ब्लॉक निर्माता कडे असलेली समावेशाची मक्तेदारी काढून टाकून FOCIL हे साध्य करते. त्याऐवजी, FOCIL अनेक प्रमाणकांना प्रत्येक ब्लॉकमध्ये व्यवहारांचा समावेश करून ब्लॉक तयार करण्यात योगदान देण्याची अनुमती देते.

उच्च-स्तरीय उद्दिष्ट अशा एका गुणधर्माचा पाठपुरावा करणे आहे ज्याला आपण चेन तटस्थता म्हणतो, ज्याचा अर्थ असा की कोणताही प्रलंबित शुल्क भरणारा व्यवहार उपलब्ध असल्यास आणि ऑनचेन समाविष्ट करण्यासाठी जागा असल्यास त्याचा समावेश केला गेला पाहिजे. आमचा असा विश्वास आहे की जर हा गुणधर्म पुरेशा प्रमाणात पूर्ण झाला, तर आपण इथेरियमची विश्वासार्ह तटस्थता वाढवू शकतो.

आपल्याला FOCIL ची आवश्यकता का आहे, आणि आताच का? (6:09)

ज्युलियन मा: आपल्याला अशा गोष्टीची आवश्यकता का आहे? सध्या जवळजवळ सर्व प्रमाणक ब्लॉक निर्मितीचे काम MEV-Boost ला आउटसोर्स करतात, जे एक प्रोटोकॉलच्या बाहेरील मार्केट आहे जिथे निर्माते ब्लॉक निर्मितीच्या अधिकारांसाठी बोली लावतात. या मार्केटमध्ये फक्त दोनच संस्थांचे खरोखर वर्चस्व आहे, आणि याचा अर्थ असा की 90% ब्लॉक फक्त दोन संस्थांद्वारे तयार केले जातात.

आपण येथे पाहतो की इथेरियम आता स्थानिक ब्लॉक निर्मितीतून आपली विश्वासार्ह तटस्थता मिळवू शकत नाही. पूर्वी ते तसे करत असे. याची सुरुवात जगभरात असलेल्या प्रस्तावकांपासून झाली, जे प्रत्येकजण त्यांचे ब्लॉक स्थानिक पातळीवर तयार करत असत, ज्याचा अर्थ असा होता की सर्व व्यवहारांचा समावेश केला जात असे. परंतु आता ब्लॉक निर्मितीचे काम या प्रगत संस्थांना आउटसोर्स केले गेल्यामुळे, हे आता पुरेसे राहिलेले नाही. त्यामुळे अधिक मजबूत सेन्सॉरशिप-विरोधी उपाय लागू करणे आवश्यक आहे, आणि असे करण्यासाठी FOCIL हा सर्वात ज्ञात आणि उत्तम मार्ग आहे.

आपण आता FOCIL का लागू करावे? तुम्हाला वाटेल की निर्माते आता तितके सेन्सॉर करत नाहीत, परंतु ते कोणत्याही क्षणी सेन्सॉर करणे सुरू करू शकतात, मग ते नियामक कारणांसाठी असो किंवा आर्थिक कारणांसाठी. आणि आर्थिक सेन्सॉरशिप ही नक्कीच अशी गोष्ट आहे जिचा गैरसमज करून घेऊ नये. जेव्हा तुलनेने कमी सेन्सॉरशिप असते तेव्हा FOCIL आणणे देखील चांगले असते, कारण तेव्हा तुम्ही ते एक बेसलाइन आणि डीफॉल्ट म्हणून सादर करता. सर्व प्रमाणक त्यांच्या अधिकारक्षेत्राची किंवा आर्थिक फायद्यांची पर्वा न करता समावेश सूची (inclusion lists) तयार करतात, आणि यामुळे मार्केटमध्ये फारच कमी अस्थिरता निर्माण होते. तर दुसरीकडे, जर सर्व निर्माते सेन्सॉर करत असताना तुम्ही FOCIL आणले, तर कदाचित ते अधिक कठीण होईल.

त्यानंतर, आजकाल बेस्ड रोलअप्स (based rollups) अधिक प्रचलित होत आहेत, आणि ते इथेरियमच्या ब्लॉक निर्मितीवर भार टाकतील. जर आपल्याला इथेरियमकडे असलेले सिक्वेन्सिंग (sequencing) प्रदान करायचे असेल, तर येथे FOCIL द्वारे विश्वासार्ह तटस्थता असणे आवश्यक आहे.

आणि तुम्ही कोणाला विचारता यावर अवलंबून, FOCIL संभाव्यतः स्केलिंगमध्ये मदत करू शकते. आजही इथेरियम स्थानिक ब्लॉक निर्मितीतून आपला सेन्सॉरशिप प्रतिकार मिळवते. जर इथेरियम इतर ठिकाणाहून सेन्सॉरशिप प्रतिकार मिळवू शकले, उदाहरणार्थ FOCIL द्वारे, तर कदाचित आपण ब्लॉक निर्मात्यांकडून असलेल्या आपल्या अपेक्षा वाढवू शकतो आणि उदाहरणार्थ, अधिक ब्लॉबना परवानगी देऊ शकतो. परंतु संभाव्यतः हे FOCIL शिवाय देखील केले जाऊ शकते. म्हणूनच, फुसाकामध्ये FOCIL लागू करण्याचा प्रस्ताव देण्यात आला आहे.

FOCIL कसे कार्य करते (8:10)

ज्युलियन मा: आता मी तुम्हाला FOCIL कसे कार्य करते हे समजावून सांगेन. आपण मूलभूत गोष्टींपासून सुरुवात करू आणि संपूर्ण यंत्रणा समजेपर्यंत टप्प्याटप्प्याने पुढे जाऊ, आणि त्यानंतर ही संपूर्ण यंत्रणा आपल्याला हव्या असलेल्या गुणधर्मांची पूर्तता कशी करते ते पाहू.

इन्क्लुजन लिस्टची मूलभूत कल्पना, जी यापूर्वी माईक न्यूडरने देखील मांडली होती, ती अशी आहे की व्यवहारांची एक सूची असते जी ब्लॉकला काही प्रकारे मर्यादित करते. उदाहरणार्थ, एक इन्क्लुजन लिस्ट आहे ज्यामध्ये A आणि B व्यवहार समाविष्ट आहेत, त्यावर प्रोटोकॉलद्वारे मान्यताप्राप्त असलेल्या एखाद्या व्यक्तीची स्वाक्षरी असते, आणि त्यानंतर हे व्यवहार एखाद्या ब्लॉकमध्ये समाविष्ट केले जाणे आवश्यक असते. FOCIL यामध्ये बदल करत नाही. ते यावरच आधारित आहे, आणि ही सूची कोण तयार करते आणि तिची अंमलबजावणी कशी केली जाते यावर अधिक लक्ष केंद्रित करते.

तर, ही सूची कोण तयार करते? FOCIL प्रोटोकॉल कसे कार्य करते याची ही पहिली पायरी आहे. प्रत्येक स्लॉटमध्ये, 16 प्रमाणकांची इन्क्लुजन लिस्ट समितीचे सदस्य म्हणून निवड केली जाते. यापैकी प्रत्येक समिती सदस्य मेमपूलचे निरीक्षण करतो आणि स्वतःची इन्क्लुजन लिस्ट तयार करतो. एक इन्क्लुजन लिस्ट सुमारे 8 किलोबाइट्स, किंवा सुमारे 20 सरासरी व्यवहारांची असावी, म्हणजेच एकूण सुमारे 320 सरासरी व्यवहार.

दुसरी पायरी म्हणजे या इन्क्लुजन लिस्ट्स वितरित करणे. इन्क्लुजन लिस्ट समितीचे सदस्य त्यांच्या इन्क्लुजन लिस्ट्स ग्लोबल टॉपिकवर वितरित करतात, आणि ते स्वतः त्यांना ब्लॉकमध्ये समाविष्ट करत नाहीत. त्यांनी हे स्लॉटच्या 9 व्या सेकंदापूर्वी करणे आवश्यक आहे, ज्या वेळी अटेस्टर्स स्थानिक इन्क्लुजन लिस्ट्सचे त्यांचे दृश्य (view) गोठवतात (freeze). आपण पुढील पायरीमध्ये पाहू तसे, अटेस्टर्सच प्रत्यक्षात या इन्क्लुजन लिस्ट्सची अंमलबजावणी करतात, जसे की नावातूनच सूचित होते: फोर्क-चॉईस एन्फोर्स्ड इन्क्लुजन लिस्ट्स. ते 9 व्या सेकंदाला कोणत्या इन्क्लुजन लिस्ट्सची अंमलबजावणी करतील याचे त्यांचे दृश्य गोठवतात, आणि यामुळे स्प्लिट-व्ह्यू अटॅक्स टळतात. ब्लॉक निर्मात्याकडे इन्क्लुजन लिस्ट्सचे निरीक्षण करण्यासाठी आणि कोणतीही इन्क्लुजन लिस्ट गहाळ झाल्यामुळे त्यावर नकारात्मक परिणाम होणार नाही याची खात्री करण्यासाठी अजूनही काही अतिरिक्त सेकंद असतात, त्यामुळे या सेटिंगमध्ये ब्लॉक निर्मात्याला कोणताही धोका नसतो.

त्यानंतर आपण अंतिम पायरीकडे वळतो, जी म्हणजे अंमलबजावणी. मी म्हटल्याप्रमाणे, अंमलबजावणी फोर्क चॉईसद्वारे केली जाते. अटेस्टर्स केवळ तेव्हाच ब्लॉकसाठी मतदान करतील जेव्हा तो इन्क्लुजन लिस्टच्या अटीची पूर्तता करेल. ते ग्लोबल टॉपिकवर पाठवलेल्या इन्क्लुजन लिस्ट्सचे निरीक्षण करून, या इन्क्लुजन लिस्ट्समध्ये त्यांनी पाहिलेल्या व्यवहारांची एकत्रित सूची बनवून, आणि नंतर हे सर्व व्यवहार ब्लॉकमध्ये आहेत की नाही हे तपासून असे करतात. जर ही तपासणी यशस्वी झाली, तर ते ब्लॉकसाठी मतदान करतात. असेही होऊ शकते की इन्क्लुजन लिस्ट्समधील सर्व व्यवहार ब्लॉकमध्ये नाहीत, परंतु ब्लॉक पूर्ण भरलेला आहे. अशा परिस्थितीत, अटेस्टर्स ब्लॉकसाठी मतदान करतात. त्यामुळे, जर ब्लॉकमध्ये व्यवहार नसतील आणि तो पूर्ण भरलेलाही नसेल, तरच अटेस्टर्स मतदान करत नाहीत; अन्यथा ते ब्लॉकसाठी मतदान करतात.

संपूर्ण यंत्रणेचा थोडक्यात आढावा घ्यायचा झाल्यास: प्रत्येक स्लॉटमध्ये, 16 समिती सदस्यांची इन्क्लुजन लिस्ट समितीचे सदस्य म्हणून निवड केली जाते. ते मेमपूलचे निरीक्षण करतात आणि इन्क्लुजन लिस्ट ऑब्जेक्ट्स तयार करतात जे ते एका अंतिम मुदतीपूर्वी, या प्रकरणात 9 व्या सेकंदापूर्वी, ग्लोबल टॉपिकवर वितरित करतात. निर्माता या इन्क्लुजन लिस्ट्सचे निरीक्षण करतो आणि त्याने पाहिलेले सर्व व्यवहार त्याच्या ब्लॉकमध्ये समाविष्ट करतो. त्यानंतर अटेस्टर्स तपासतात की त्यांनी 9 व्या सेकंदापूर्वी इन्क्लुजन लिस्ट्समध्ये पाहिलेले सर्व व्यवहार खरोखरच ब्लॉकमध्ये आहेत की नाही. जर ही तपासणी यशस्वी झाली, तर ते ब्लॉकसाठी मतदान करतात, आणि आपण पुढील स्लॉटवर जातो, जिथे पुन्हा हीच प्रक्रिया घडते.

IL Boost आणि अनक्राउडेबिलिटी (11:07)

ज्युलियन मा: माईकच्या मागील EIP साठी आणि त्यानंतरच्या विकासादरम्यान व्यक्त केलेली, इन्क्लूजन लिस्ट्सबद्दलची एक मोठी चिंता म्हणजे "IL Boost," किंवा अनक्राउडेबिलिटी. याचा संदर्भ या वस्तुस्थितीशी आहे की इन्क्लूजन लिस्ट प्रस्तावक इन्क्लूजन लिस्ट तयार करण्याचे त्यांचे अधिकार विकू इच्छितात. ही एक अतिशय तार्किक चिंता आहे, कारण आपण ब्लॉक निर्मितीच्या बाबतीत हे घडताना पाहतो: हा अधिकार विकल्याने अत्याधुनिक निर्मात्यांची एक केंद्रित बाजारपेठ तयार होते.

आम्ही असा युक्तिवाद करतो की खालील गुणधर्मांमुळे FOCIL या MEV-Boost सारख्या बाजारपेठांच्या किंवा ज्यांना बोलीभाषेत IL Boost म्हणून ओळखले जाते, त्यांच्या विरुद्ध मजबूत आहे. FOCIL व्यवहारांच्या कोणत्याही क्रमाची हमी देत नाही. तुम्ही तुमचा व्यवहार तुमच्या इन्क्लूजन लिस्टमध्ये कुठेही ठेवला तरीही, ब्लॉक निर्माता त्याला योग्य वाटेल त्या क्रमाने तो लावेल. उदाहरणार्थ, जर तुम्ही लिस्टमध्ये आर्बिट्रेज (arbitrage) व्यवहाराचा समावेश केला, तर निर्माता तुमचा आर्बिट्रेज व्यवहार ब्लॉकच्या शीर्षस्थानी ठेवेल जेणेकरून तो प्रत्यक्षात आर्बिट्रेजची अंमलबजावणी करेल, याची शक्यता फारच कमी आहे. त्याऐवजी, निर्माता बहुधा ते स्वतःच करेल.

शिवाय, खाजगी ऑर्डर फ्लो शक्य नाही. या इन्क्लूजन लिस्ट्स जागतिक स्तरावर वितरीत केल्या जातात, त्यामुळे निर्मात्याने ब्लॉक तयार करण्यापूर्वी तुमचे व्यवहार सार्वजनिक असतात. इन्क्लूजन लिस्टद्वारे खाजगी ऑर्डर फ्लो ब्लॉकमध्ये प्रवेश करणे शक्य नाही.

तिसरे म्हणजे, प्रति स्लॉट अनेक इन्क्लूजन लिस्ट प्रस्तावक असतात. जरी विकण्यासाठी काही मौल्यवान गोष्ट असली, तरीही सर्व 16 इन्क्लूजन लिस्ट समिती सदस्यांना ही इन्क्लूजन लिस्ट तयार करण्याची समान संधी असते, त्यामुळे त्या इन्क्लूजन लिस्ट प्रस्तावकांमधील स्पर्धा त्याचे मूल्य शून्यावर आणेल.

आणि शेवटी, या इन्क्लूजन लिस्ट्स ब्लॉक उत्पादकाने कृती करण्याच्या 3 सेकंद आधी तयार केल्या जातात. अतिरिक्त माहितीचे 3 सेकंद असतात, जे सहसा MEV प्रकारच्या व्यवहारांसाठी अत्यंत प्रासंगिक असतात, जे इन्क्लूजन लिस्ट निश्चित झाल्यानंतर आणि ब्लॉक उत्पादकाने कृती करण्यापूर्वी येतात, याचा अर्थ असा की माहितीचा फायदा खूपच कमी असतो. खरेतर, जे लोक MEV साठी एक साधन म्हणून इन्क्लूजन लिस्ट्स वापरण्याचा प्रयत्न करत आहेत त्यांच्यासाठी माहितीचा तोटाच आहे.

या कारणांमुळे, आमचा असा विश्वास आहे की कोणत्याही वैयक्तिक इन्क्लूजन लिस्ट प्रस्तावकाकडे समावेशन, क्रमवारी किंवा वगळण्याची शक्ती नाही, जी MEV ची मूलभूत व्याख्या आहे. म्हणून इन्क्लूजन लिस्ट्स MEV च्या अधीन नसाव्यात.

सादरीकरणाचा सारांश (13:09)

ज्युलियन मा: या जलद सादरीकरणाचा सारांश सांगायचा तर: FOCIL अनेक प्रमाणकांना ब्लॉक निर्मितीमध्ये योगदान देण्याची अनुमती देते, ज्यामुळे एकाच प्रस्तावकाची समावेशावरील मक्तेदारी टळते आणि इथेरियमची विश्वासार्ह तटस्थता वाढते. आमचा असा विश्वास आहे की आता FOCIL लागू करणे आवश्यक आहे कारण सध्या फक्त दोन प्रमुख निर्माते आहेत जे कोणत्याही क्षणी सेन्सॉरशिप सुरू करू शकतात, आणि हे आर्थिक कारणांसाठी असू शकते ज्याचा त्यांना फायदा होऊ शकतो. ब्लॉक निर्मिती अधिक भार पेलणारी बनू शकते कारण आधारित रोलअप्स इथेरियमच्या अनुक्रमणिका गुणधर्मांचा वापर करू इच्छितील. जेव्हा सेन्सॉर करणारे पक्ष कमी असतील तेव्हा FOCIL अधिक सुरळीतपणे लाँच होईल: पहिले, कारण याचा अर्थ असा आहे की प्रमाणकांसाठी समावेश सूची तयार करणे हे डीफॉल्ट आहे, आणि दुसरे म्हणजे, सेन्सॉर करणारे निर्माते आणि सेन्सॉर न करणारे निर्माते यांच्यात बाजारातील अस्थिरता कमी असेल. आणि शेवटी, FOCIL संभाव्यतः स्केलिंगमध्ये मदत करू शकते, जो कदाचित असा विषय आहे ज्यावर आपण अधिक सविस्तर चर्चा करू शकतो.

हे छोटे सादरीकरण करण्यासाठी वेळ दिल्याबद्दल धन्यवाद. ज्यांना स्वारस्य आहे त्यांच्यासाठी मला फक्त QR कोड दाखवायचा होता, जो EIP कडे घेऊन जातो.

पूजा रंजन: या जलद सादरीकरणाबद्दल आणि प्रस्तावाच्या विहंगावलोकनाबद्दल खूप खूप धन्यवाद.

प्रश्न आणि उत्तरे: EIP-7805 हे EIP-7547 पेक्षा कसे वेगळे आहे? (14:17)

पूजा रंजन: मी प्रश्न आणि उत्तरे (Q&A) सत्राची सुरुवात अगदी पहिल्या प्रश्नाने करू इच्छिते, जो तुमच्या सादरीकरणात नमूद केलेल्या आधीच्या प्रस्तावाबद्दल आहे: माईक न्यूडर यांचा प्रस्ताव 7547, इन्क्लूजन लिस्ट्स (inclusion lists). मला त्या प्रस्तावात आणि 7805 मधील FOCIL मध्ये असलेला मूलभूत फरक समजून घ्यायचा आहे. तुम्ही तुमच्या सादरीकरणात IL Boost आणि अनक्राउडेबिलिटी (uncrowdability) बद्दल थोडक्यात माहिती दिली होती. तुम्ही याबद्दल थोडे अधिक स्पष्टीकरण देऊ शकाल का?

ज्युलियन मा: 7805 हे 7547 पेक्षा कसे वेगळे आहे याचे उत्तर देण्यासाठी कदाचित थॉमस सर्वात योग्य व्यक्ती आहे, पण मी याबद्दल थोडे सांगू शकतो. सर्वप्रथम, FOCIL हे त्याच स्लॉटसाठी आहे, तर 7547 हे पुढील स्लॉटसाठी होते. सेम-स्लॉट (same-slot) वैशिष्ट्यामुळे काही गोष्टी सोप्या होतात, कारण याचा अर्थ असा की इन्क्लूजन लिस्ट ऑनचेन स्टोअर करावी लागत नाही.

अनक्राउडेबिलिटी वैशिष्ट्याबद्दल बोलायचे झाल्यास, हे खूप मनोरंजक आणि सूक्ष्म आहे. 7547 मध्ये, जो एक उत्तम प्रस्ताव होता आणि ज्यावर आमचा प्रस्ताव आधारित आहे, इन्क्लूजन लिस्ट विनाअट ब्लॉकच्या तळाशी जोडली जाते आणि ती एकाच व्यक्तीद्वारे बनविली जाते. याची काही वैशिष्ट्ये आमच्यापेक्षा वेगळी आहेत. सर्वप्रथम, व्यवहार क्रमाने लावले जातात. भविष्यात बॉटम-ऑफ-ब्लॉक आर्बिट्रेज (bottom-of-block arbitrage) असणे खूप मौल्यवान असू शकते आणि थॉमसच्या काही संशोधनांनी हे अधोरेखित केले आहे की हे संभाव्यतः एक मौल्यवान ठिकाण असू शकते. इन्क्लूजन लिस्ट बनवण्याचे अधिकार असणे म्हणजे तुम्ही ब्लॉकमध्ये कृती करणारे शेवटचे व्यक्ती आहात आणि काही प्रकरणांमध्ये हे मौल्यवान असू शकते. दुसरे म्हणजे, ती एकाच व्यक्तीद्वारे बनविली जाते, त्यामुळे इन्क्लूजन लिस्ट समिती सदस्यांमध्ये हा स्पर्धात्मक प्रभाव नसतो. एका व्यक्तीच्या समितीला ब्लॉकच्या तळाशी व्यवहारांचा समावेश करण्याचा पूर्ण अधिकार असतो, ज्यामुळे ते अधिक मौल्यवान देखील होऊ शकते. तिसरे म्हणजे, हे विनाअट वैशिष्ट्य आहे, ज्याचा अर्थ असा की ब्लॉक निर्माता काहीही करत असला तरीही, तुमचा व्यवहार ऑनचेन समाविष्ट केला जाईल. त्यामुळे यात समावेशासाठी आवश्यक असलेल्या किमान मर्यादेपलीकडे काही अतिरिक्त हमी आहेत, ज्यामुळे ते काही प्रमाणात मौल्यवान बनू शकते.

थॉमस थियरी: आमच्याकडे असलेल्या इन्क्लूजन लिस्ट प्रस्तावकांची संख्या हा देखील एक मोठा फरक आहे. मागील प्रस्तावात, अशी एक यंत्रणा होती ज्याद्वारे स्लॉट n चा प्रस्तावक इन्क्लूजन लिस्ट बनवतो जी स्लॉट n+1 च्या प्रस्तावकाला लागू करणे आवश्यक असते. येथे दोन मोठ्या गोष्टी आहेत: पहिली, यात एक-स्लॉटचा विलंब आहे, त्यामुळे इन्क्लूजन लिस्टमधील व्यवहार केवळ पुढील प्रस्तावकाद्वारे पुढील स्लॉटमध्ये समाविष्ट केले जाणे आवश्यक आहे. आणि प्रत्यक्षात इन्क्लूजन लिस्ट बनवणारा फक्त एकच प्रस्तावक असतो. FOCIL सह आमच्याकडे 16 आहेत. यामुळे खूप मोठा फरक पडतो, कारण संपूर्ण यंत्रणा अपेक्षेप्रमाणे काम करण्यासाठी आता आम्हाला 16 IL समिती सदस्यांपैकी फक्त एकाने प्रामाणिक असण्याची आवश्यकता आहे. हे खरोखरच एक चांगली सेन्सॉरशिप-प्रतिरोधक (censorship-resistant) यंत्रणा असण्याची तुमची शक्यता वाढवते, तर यापूर्वी तुम्ही एकाच पक्षावर अवलंबून होता.

आणि त्यानंतर काही अधिक तांत्रिक तपशील: खाते अमूर्तीकरण सोबत काही विसंगती होत्या, आणि IL दुटप्पीपणा हाताळणे कठीण होते, म्हणजे कोणीतरी दोन वेगवेगळ्या इन्क्लूजन लिस्ट्स पाठवणे. ब्लॉक दुटप्पीपणा ही एक ज्ञात गोष्ट आहे आणि प्रोटोकॉलद्वारे त्याला दंड आकारला जातो, परंतु मागील प्रस्तावात सर्वकाही ऑनचेन गेल्यामुळे, तुम्हाला विचित्र एज केसेस (edge cases) देखील हाताळाव्या लागल्या आणि त्यांना सामावून घेणे फार सोपे नव्हते. FOCIL सह, इन्क्लूजन लिस्ट्स ऑनचेन जात नाहीत. त्या फक्त P2P सहमती स्तर नेटवर्कवर प्रसारित केल्या जातात. हे थोडे तांत्रिक आहे, परंतु खाते अमूर्तीकरणामुळे उद्भवणाऱ्या या एज केसेस हाताळण्यात, किंवा IL दुटप्पीपणासह नेटवर्कला दोन दृश्यांमध्ये विभाजित करणाऱ्या हल्ल्यांना हाताळण्यात यामुळे मोठा फरक पडतो.

पूजा रंजन: खूप खूप धन्यवाद. ज्या लोकांना प्रस्ताव 7547 बद्दल अधिक जाणून घ्यायचे आहे, त्यांच्यासाठी आमच्याकडे माईक न्यूडर यांच्यासोबतचा एक रेकॉर्ड केलेला भाग आहे, PEEPanEIP चा भाग 130, जो एक उच्च-स्तरीय विहंगावलोकन प्रदान करतो. मला नेहमीच स्पर्धात्मक प्रस्ताव पाहायला आवडतात, कारण मला माहित आहे की ते इकोसिस्टम आणि चेनच्या भल्यासाठी असते. मला चॅटमध्ये काही प्रश्न दिसत आहेत. कदाचित मी कातायाला तिचा प्रश्न विचारण्यासाठी आमंत्रित करू इच्छिते.

प्रस्तावकाला सर्व 16 याद्या समाविष्ट कराव्या लागतात का? (19:05)

कटाया: नमस्कार, धन्यवाद. माझा प्रश्न असा होता की: ब्लॉक प्रस्तावकाला 16 समावेशन याद्या मिळतात का, ज्यातील प्रत्येक यादी एका समिती सदस्याकडून येते, आणि त्याला या याद्यांमधील सर्व व्यवहार समाविष्ट करावे लागतात का?

थॉमस थियरी: होय, ते बरोबर आहे. तुम्ही सर्व याद्यांमधील सर्व व्यवहारांचे एकत्रीकरण करता, आपल्या बाबतीत 16 याद्या. साहजिकच, यात काही समान व्यवहार असू शकतात, त्यामुळे तुम्ही त्यांचे एकत्रीकरण करता आणि डुप्लिकेट्स काढून टाकता, पण होय, ब्लॉकला प्रमाणकांद्वारे वैध मानले जाण्यासाठी सर्व याद्यांमधील सर्व व्यवहार ब्लॉकमध्ये समाविष्ट करणे आवश्यक आहे.

पूजा रंजन: चॅटमधील पुढचा प्रश्न जस्टिनचा आहे. जस्टिन, तू तुझा प्रश्न पाहुण्यांसाठी वाचू इच्छितोस का?

समावेशन सूचीमध्ये खाजगी मेमपूल व्यवहार (19:55)

जस्टिन: मी आतापर्यंत खूप प्रश्न विचारले आहेत. मला विचारायचे होते की खाजगी मेमपूलमधील व्यवहार समावेशन सूचीमध्ये टाकण्यापासून काय प्रतिबंधित करते, आणि मला वाटते की याचे बऱ्यापैकी उत्तर दिले गेले आहे. हे पूर्णपणे ठीक आहे असे वाटते, कारण निर्माता मुळात त्यांना योग्य वाटेल तसा त्यांचा क्रम लावणार आहे, आणि जेव्हा तुमचा व्यवहार IL वर जातो तेव्हा तो सार्वजनिक देखील होतो. त्यामुळे मला वाटते की हे योग्य आहे. धन्यवाद.

थॉमस थियरी: ज्युलियनने नमूद केल्याप्रमाणे, हा एक विचार होता. आम्हाला खरोखरच FOCIL आणि समावेशन सूचीचा वापर MEV व्यवहार, खाजगी ऑर्डर प्रवाह किंवा पूर्व-पुष्टीकरणांचा समावेश करण्यासाठी व्हावा असे वाटत नव्हते, कारण शेवटी आम्हाला सेन्सॉरशिप प्रतिकार हवा आहे, आणि जर तुम्ही काळजी घेतली नाही तर एखाद्या यंत्रणेसाठी मौल्यवान व्यवहारांचा समावेश करण्याचे साधन बनणे खूप सोपे आहे. जेव्हा तुम्ही तुमचा व्यवहार समावेशन सूचीमध्ये समाविष्ट करता तेव्हा तो आपोआप सार्वजनिक होतो, प्रत्येकजण तो पाहू शकतो, त्याला कोणत्याही क्रमाची हमी नसते, आणि तो निर्मात्याद्वारे ब्लॉकमध्ये कुठेही समाविष्ट केला जाऊ शकतो, ही वस्तुस्थिती त्याला मौल्यवान व्यवहारांसाठी फारशी योग्य बनवत नाही.

त्यामुळे एकतर तुमच्याकडे सार्वजनिक व्यवहार असतो, आणि तो समावेशन सूचीमध्ये समाविष्ट करण्यासाठी तुम्ही तो फक्त सार्वजनिक मेमपूलमध्ये सबमिट करू शकता, किंवा तुमच्याकडे मौल्यवान खाजगी व्यवहार असतात, आणि मग तुम्ही FOCIL द्वारे जाणार नाही, कारण ते करण्यासाठी इतर चांगले मार्ग आहेत. तुम्ही थेट निर्मात्याशी संपर्क साधाल आणि खाजगी चॅनेलद्वारे ते पाठवाल.

पूजा रंजन: माहिती शेअर केल्याबद्दल धन्यवाद. मला दिसतेय की पुढचा प्रश्न लॅडिस्लॉसचा आहे.

FOCIL आणि स्केलिंग (21:41)

लॅडिस्लॉस: नमस्कार मित्रांनो. हे तुम्ही FOCIL आणि स्केलिंगच्या संदर्भात मांडलेल्या मुद्द्याशी संबंधित आहे. आपण सर्वांनी पाहिल्याप्रमाणे, मी अलीकडे इथेरियम स्केलिंगवर काही चर्चा पाहिली आहे, आणि तुम्ही योग्यरित्या नमूद केल्याप्रमाणे, तिथे काही मोजक्याच निर्मात्यांची अडचण आहे. मला वैयक्तिकरित्या FOCIL कडे स्थानिक निर्मितीला पुन्हा सक्षम करणारे म्हणून पाहायला आवडते, आणि बँडविड्थ आवश्यकता किंवा सर्वसाधारणपणे नोड आवश्यकता वाढवण्यापूर्वी ते प्रोटोकॉलमध्ये समाविष्ट करणे आवश्यक आहे असे मला वाटते. कदाचित तुम्ही याबद्दल काय विचार करता, आणि तुम्ही नमूद केल्याप्रमाणे FOCIL शिवाय स्केलिंगच्या इतर संभाव्य मार्गांबद्दल अधिक सविस्तर सांगू शकाल.

ज्युलियन मा: प्रश्नाबद्दल धन्यवाद. सर्वप्रथम, FOCIL द्वारे स्केलिंगचा विचार करूया. सध्या 90% प्रमाणक MEV-Boost द्वारे ब्लॉक निर्मितीचे काम बाहेरून करून घेतात, आणि या प्रगत संस्थांकडे किमान हार्डवेअर आवश्यकतांपेक्षा स्पष्टपणे अधिक बँडविड्थ असते. उदाहरणार्थ, ते कोणत्याही समस्येशिवाय त्यांच्या ब्लॉकमध्ये अधिक ब्लॉब्स समाविष्ट करू शकतात. तरीही, एक मनोरंजक गोष्ट अशी आहे की इथेरियम विश्वासार्ह तटस्थतेसाठी किंवा सेन्सॉरशिप प्रतिकारासाठी स्थानिक ब्लॉक निर्मितीवर अवलंबून असते, कारण या दोन प्रगत संस्था अशा नाहीत ज्यांच्यावर इथेरियमचा सेन्सॉरशिप प्रतिकार तयार केला जाऊ शकतो.

त्यामुळे इथेरियम प्रोटोकॉलची रचना अद्यापही अशी असली पाहिजे की स्थानिक ब्लॉक निर्मिती करणे शक्य होईल, आणि किंबहुना आम्ही त्याची रचना अशी करतो की ते MEV-Boost च्या तुलनेत तोट्याचे ठरणार नाही. हे इथेरियमच्या रचनेत आहे, परंतु प्रत्यक्षात, अर्थातच, MEV-Boost अधिक फायदेशीर आहे: पहिले कारण म्हणजे या प्रगत ब्लॉक निर्मात्यांकडे अधिक गुंतागुंतीचे अल्गोरिदम असतात, आणि दुसरे म्हणजे त्यांच्याकडे खूप जास्त खाजगी ऑर्डर फ्लो असतो. अलीकडेच Data Always ने केलेल्या काही संशोधनातून असे दिसून आले आहे की MEV-Boost ब्लॉकमध्ये खूप जास्त व्यवहार असतात. केवळ यामुळेच अधिक नफा मिळतो.

तरीही, प्रोटोकॉलची रचना अशी केली आहे की प्रोटोकॉलच्या नियमांमधून अशी कोणतीही सक्ती नाही ज्यामुळे एक प्रमाणक दुसऱ्यापेक्षा कमी फायदेशीर ठरेल. जर आपल्याला तो नियम ठेवायचा असेल, तर FOCIL आवश्यक आहे, कारण तेव्हा स्थानिक ब्लॉक निर्माते समावेशन सूचीमध्ये योगदान देऊ शकतात आणि त्याद्वारे सेन्सॉरशिप प्रतिकार कायम ठेवू शकतात. तथापि, आपण या नियमातून मुक्त होऊ शकतो आणि मुळात असे म्हणू शकतो की स्थानिक ब्लॉक निर्माते ठराविक संख्येने ब्लॉब्स समाविष्ट करू शकतात, परंतु अधिक प्रगत ब्लॉक निर्माते अधिक ब्लॉब्स समाविष्ट करू शकतात, इतक्या प्रमाणात की स्थानिक ब्लॉक निर्माते स्वतः ब्लॉक तयार करताना तो भार हाताळू शकणार नाहीत. त्यामुळे जर आपल्याला हा नियम ठेवायचा असेल की कमाल मर्यादा सर्वात कमी हार्डवेअर आवश्यकतांवर सेट केली आहे, तर आपल्याला FOCIL ची आवश्यकता आहे. जर आपण तो नियम शिथिल करण्यास तयार असू, तर कदाचित आपल्याला स्केलिंगसाठी FOCIL ची आवश्यकता भासणार नाही.

थॉमस थियरी: मला वाटते हे अगदी समान आहे, परंतु सध्या इथेरियमवर आपण एका विचित्र स्थितीत आहोत, कारण आपण बहुतांश ब्लॉक तयार करण्यासाठी प्रगत निर्मात्यांवर अवलंबून आहोत, परंतु ते सेन्सॉरशिप प्रतिकारासाठी चांगले नाहीत, कारण ते फक्त दोन पक्ष आहेत. जर त्यांनी काही अनियंत्रित कारणास्तव व्यवहार किंवा काही पत्ते सेन्सॉर करण्याचे ठरवले, तर मुळात आपल्याकडे सेन्सॉरशिप प्रतिकार किंवा परवानगीविरहितता उरणार नाही, जे खूप महत्त्वाचे आहे. याचा अर्थ ते ऑनचेन सहभागी होण्यापासून त्यांना पाहिजे असलेल्या कोणत्याही घटकांना सेन्सॉर करू शकतात किंवा रोखू शकतात, जे खूप वाईट आहे.

आणि आपण जे सेन्सॉरशिप प्रतिकार गुणधर्म ठेवतो ते आश्चर्यकारक नाहीत, बरोबर? बहुतांश ब्लॉक या दोन निर्मात्यांद्वारे तयार केले जात असल्याने, तुम्हाला मुळात एक स्थानिक ब्लॉक निर्माता निवडला जाईपर्यंत आणि सामान्यतः सेन्सॉर केलेले हे सर्व व्यवहार समाविष्ट करणारा ब्लॉक प्रस्तावित करेपर्यंत प्रतीक्षा करावी लागते, जे चांगले वाटत नाही. याचा अर्थ या वापरकर्त्यांना त्यांचे व्यवहार प्रत्यक्षात ऑनचेन समाविष्ट होईपर्यंत 10, 12, मला माहित नाही, अनेक ब्लॉक्सची प्रतीक्षा करावी लागेल.

त्यामुळे आपल्याला खरोखरच होम स्टेकर आणि स्थानिक ब्लॉक निर्माते ठेवायचे आहेत, कारण तेच सेन्सॉरशिप प्रतिकार जतन करतात. त्याच वेळी, आज, त्यांचा वापर करणे देखील चांगले नाही, कारण जर तुमचे व्यवहार दोन निर्मात्यांद्वारे सेन्सॉर केले गेले असतील तर ते समाविष्ट करण्यासाठी तुम्हाला अद्याप बराच वेळ प्रतीक्षा करावी लागते. FOCIL सह, तुम्ही अशा जगात जाता जिथे सेन्सॉरशिप प्रतिकाराची हमी देणारे सहभागी, आपल्या बाबतीत समावेशन सूची समितीचे सदस्य, ब्लॉक तयार करणाऱ्या लोकांपेक्षा वेगळे असू शकतात. मला वाटते की हे एक अतिशय मनोरंजक परिदृश्य उघडते, कारण आता आपल्याला मौल्यवान ब्लॉक तयार करण्यासाठी आणि सेन्सॉरशिप प्रतिकारात योगदान देण्यासाठी एकाच सहभागीवर अवलंबून राहावे लागणार नाही. FOCIL ला त्या महत्त्वाच्या दिशेने पहिले पाऊल देखील मानले जाऊ शकते, कारण तुमच्याकडे दोन अतिशय भिन्न कर्तव्ये आहेत, आणि आज आपण एकाच प्रमाणक नोड्सना दोन्ही करण्यास सांगतो, जे खूप तणावपूर्ण आहे.

पूजा रंजन: खूप खूप धन्यवाद. मला वाटते पुढचा प्रश्न लुईसचा आहे.

व्यवहार निवडण्यासाठी निकष (26:46)

लुईस पिंटो: मी सुरुवातीनंतर काही मिनिटांनी सामील झालो, परंतु मला असे दिसते की हे संपूर्ण नेटवर्कमध्ये व्यवहार निवड विकेंद्रित करत आहे. माझ्या मते हे खूप चांगले आहे; हे MEV आणि सेन्सॉरशिप विरुद्ध लढते. आणि मला अटेस्टर्सनी (attesters) हे काम करण्याचा भाग नक्कीच आवडला, कारण भविष्यात त्यांच्याकडे निर्मात्यांपेक्षा कमी हार्डवेअर आवश्यकता असतील, विशेषतः अवस्थाहीनता आणि अवस्थाहीन क्लायंट्ससह. हे अगदी कमी हार्डवेअरवर चालवणे शक्य असल्याने, यामुळे गोष्टी खूप विकेंद्रित होतात. मला वाटते की येथील मुख्य आव्हान या समावेशन सूचींच्या (inclusion lists) व्यवहार निवडीसाठी निकष परिभाषित करणे हे आहे, मग तुम्ही प्राधान्य शुल्क (priority fees) किंवा ब्लॉब्सच्या संख्येशी जा; यात अनेक व्हेरिएबल्स आहेत. तुम्ही लागू करण्याचा विचार करत असलेल्या निकषांच्या संचावर तुम्ही पोहोचला आहात का?

थॉमस थियरी: हा एक उत्तम प्रश्न आहे. याचे दोन भाग आहेत. पहिला भाग खूप महत्त्वाचा आहे, जो ब्लॉक तयार करणाऱ्या किंवा प्रस्तावित करणाऱ्या लोकांपासून अटेस्टर्सना वेगळे करण्याबद्दल आहे. हे संपूर्ण अटेस्टर-प्रस्तावक विभाजन (APS) संशोधनाचे क्षेत्र आहे; ज्युलियनने यावर बरेच काम केले आहे. आम्ही याला भूमिकांचे विभाजन (unbundling roles) म्हणतो, जेणेकरून ते प्रोटोकॉलच्या कर्तव्यांशी अधिक जवळून जुळतील. मी एका संभाव्य विभाजनाबद्दल एक पोस्ट लिहिली आहे, जी मी नुकतीच शेअर केली आहे, ती खूप खुली आहे आणि मला लोकांकडून अधिक मते जाणून घ्यायला आवडेल. या पोस्टमध्ये मी अटेस्टर्स, समाविष्ट करणारे (includers) जे आता IL समिती सदस्य आहेत, आणि अंमलबजावणी प्रस्तावक किंवा निर्माते यांच्यात विभाजन केले आहे. मला वाटते की ही मूलभूतपणे भिन्न कर्तव्ये आहेत आणि कदाचित त्यांच्यासाठी आपल्याकडे वेगवेगळ्या भूमिका असाव्यात.

त्यानंतर, समावेशन नियमाबद्दल (inclusion rule), हा एक अतिशय चांगला प्रश्न आहे. आम्ही यावर बराच विचार केला आणि मला वाटते की आम्ही दोन गोष्टींवर पोहोचलो आहोत. पहिली गोष्ट म्हणजे आम्हाला नियमांमध्ये विविधता हवी आहे. आम्हाला एकच नियम नको आहे, उदाहरणार्थ सर्व क्लायंट्ससाठी उतरत्या प्राधान्य शुल्कानुसार क्रमवारी लावणे, कारण तसे केल्यास तुम्ही प्रत्यक्षात खेळ खेळू शकता आणि मेमपूलची पुनर्रचना करण्याचा प्रयत्न करू शकता जेणेकरून केवळ तुमचेच व्यवहार ILs मध्ये समाविष्ट होतील. परंतु जर तुमच्याकडे नियमांची विविधता असेल, ज्यामध्ये असा एक नियम असेल जो मेमपूलमध्ये व्यवहार किती काळ प्रलंबित आहे हे देखील विचारात घेतो, आणि भिन्न क्लायंट्स भिन्न नियम लागू करतात, जे सर्व एकाच स्वरूपाचे असतात, मुख्यतः प्राधान्य शुल्क आणि मेमपूलमधील प्रलंबित वेळेभोवती, तर यात फेरफार करणे खूप, खूप कठीण होते आणि यामुळे प्रोटोकॉल अधिक मजबूत होतो. मला वाटते की, आज इथेरियमवर असलेल्या क्लायंट्सच्या विविधतेचा फायदा घेण्याचा आणि क्लायंट्सना स्वतःच्या मतानुसार निवड करू देण्याचा हा एक चांगला मार्ग आहे. आमच्या मनात काही नियम आहेत, परंतु आम्हाला वाटते की क्लायंट्स त्यांच्यासाठी सर्वोत्तम नियम देखील निवडू शकतात. जोपर्यंत प्रत्येकाकडे प्राधान्य शुल्कानुसार क्रमवारी लावलेला अगदी सारखाच नियम नाही, तोपर्यंत आपण सुरक्षित राहू.

लुईस पिंटो: ठीक आहे, म्हणजे तुम्ही हे निकष देखील वितरित करत आहात, जे समावेशन सूची तयार करतात त्यांना त्यांचे स्वतःचे निकष ठेवू देत आहात. की हा प्रोटोकॉलचा भाग असणार आहे?

ज्युलियन मा: समावेशन नियम प्रोटोकॉलचा भाग असणार नाही. सर्वप्रथम, याची अंमलबजावणी करणे खूप कठीण आहे आणि दुसरे म्हणजे, प्रत्यक्षात कोणतीही सक्ती न करणे चांगले आहे. जर आपण समिती सदस्यांना स्वतः निर्णय घेण्याची परवानगी दिली, किंवा क्लायंट टीम्सना त्यांच्या वतीने कार्य करू दिले की ते व्यवहार कसे समाविष्ट करतात, तर आपण नेटवर्कमध्ये काही प्रमाणात मजबुती निर्माण करतो. भिन्न प्राधान्ये असलेले लोक वेगवेगळ्या प्रकारे समाविष्ट करतील, ज्याचा अर्थ असा की सिस्टमवर हल्ला करणे कठीण आहे.

लुईस पिंटो: ठीक आहे, धन्यवाद.

EIP-7702, ePBS, आणि PeerDAS सह सुसंगतता (30:43)

पूजा रंजन: खूप खूप धन्यवाद. मला समजल्याप्रमाणे, हा प्रस्ताव पेक्ट्रा नंतरच्या अपग्रेडसाठी, फुसाकासाठी आधीच प्रस्तावित केला गेला आहे. आणि फुसाकामध्ये प्रगतीपथावर असलेले इतर काही EIPs समाविष्ट असू शकतात किंवा नसूही शकतात, त्यामुळे मला प्रश्न पडला आहे की खाते अमूर्तीकरण, ePBS आणि PeerDAS साठी असलेल्या 7702 सारख्या प्रस्तावांच्या संदर्भात FOCIL च्या सुसंगततेची स्थिती काय आहे.

थॉमस थियरी: उत्तम प्रश्न. इन्क्लूजन लिस्ट्सच्या (समावेशन सूची) इतिहासामुळे आम्हाला येथे थोडा फायदा झाला. आम्ही नमूद केल्याप्रमाणे, 7547 चा समावेशासाठी विचार केला गेला होता आणि नंतर विसंगतीमुळे तो नाकारला गेला. त्यामुळे नवीन प्रस्ताव मांडण्यापूर्वी त्या सोडवण्याबाबत आम्ही खूप काळजी घेतली, कारण आम्हाला माहित होते की लोक त्याच प्रश्नांसह याकडे पाहणार आहेत, जे साहजिकच आहे.

आम्हाला खूप आत्मविश्वास आहे, कारण आम्ही खाते अमूर्तीकरण टीम्सशी देखील बोललो आहोत, आणि आम्ही पोटुझ (Potuz) आणि टेरेन्स (Terence) यांच्याशी खूप चर्चा केली. टेरेन्स आम्हाला सक्रियपणे मदत करत आहे, आणि तो ePBS आणि FOCIL दोन्हीवर काम करत आहे, त्यामुळे ते सुसंगत आहे की नाही हे तपासणे आमच्यासाठी खूप सोपे होते. मला खरोखर वाटत नाही की इतर कोणत्याही EIPs सोबत काही विसंगती आहेत. ePBS च्या बाबतीत, तुम्हाला वेळेबाबत काळजी घ्यावी लागते, कारण तुम्ही अंमलबजावणी पेलोड एकमत ब्लॉकपासून वेगळे करता, त्यामुळे संपूर्ण स्लॉटची वेळ बदलते, आणि आता तुम्ही ILs ची निर्मिती देखील जोडता जे पेलोड प्रस्तावित होण्यापूर्वी तयार करणे आवश्यक आहे. त्यामुळे तुम्हाला वेळेबाबत काळजी घेणे आवश्यक आहे, परंतु जर मला बरोबर आठवत असेल, तर गेल्या वेळी जेव्हा आम्ही पोटुझ आणि टेरेन्स या दोघांशी याबद्दल बोललो होतो, तेव्हा कोणतीही मोठी विसंगती नव्हती. मला वाटते की सुसंगततेच्या बाबतीत आपली स्थिती चांगली आहे.

पूजा रंजन: हे जाणून आनंद झाला. माझ्या लक्षात आले की जिहूनने (Jihoon) एक HackMD देखील शेअर केले आहे, जे आम्ही संसाधनांमध्ये जोडू, ज्या लोकांना विशेषतः ePBS सह सुसंगततेबद्दल अधिक जाणून घ्यायचे आहे त्यांच्यासाठी. आणि हो, माईकसोबतच्या (Mike) गेल्या संभाषणावरून मला आठवते, मला वाटते की खाते अमूर्तीकरणाच्या विसंगतीमुळे हा प्रस्ताव समाविष्ट केला गेला नव्हता. त्यामुळे याची आधीच काळजी घेतली गेली आहे हे जाणून आनंद झाला.

FOCIL आणि मल्टी-स्लॉट MEV (33:04)

पूजा रंजन: मी FOCIL वेबसाइट, meetfocil.eth.limo वर जोडलेले दस्तऐवज आणि तपशील वाचत होते, आणि मला मल्टी-स्लॉट MEV (multi-slot MEV) नावाच्या संज्ञेबद्दल माहिती मिळाली. ज्युलियनने असेही नमूद केले की डेव्हलपर्सनी ते समान पातळीवर ठेवण्याची इच्छा आणि प्रयत्न करूनही, MEV-Boost सर्वसाधारणपणे फायदेशीर आहे. मला प्रश्न पडला आहे की FOCIL याला कसे रोखेल.

ज्युलियन मा: तुमच्या प्रश्नाबद्दल धन्यवाद. प्रथम, मी FOCIL आणि MEV बद्दल काहीतरी सांगतो, आणि मग आपण मल्टी-स्लॉट MEV कडे वळूया. FOCIL आवश्यकपणे MEV ला रोखत नाही, आणि याचे नेमके कारण हे आहे की आम्हाला MEV भाग आणि समावेश (inclusion) भाग वेगळे करायचे आहेत. आमच्या मते असे करणे महत्त्वाचे आहे, कारण अन्यथा IL Boost सारखे मार्केट्स उभे राहतील. त्या तर्कानुसार, जर समावेश सूची (inclusion list) काढता येण्याजोग्या MEV चे प्रमाण मर्यादित करू शकली, तर समावेश सूची तयार करणे खूप मौल्यवान बनते, आणि लोक त्याभोवती मार्केट्स तयार करतील. आमचे डिझाइन खरोखरच किमान समावेशाची हमी (minimum inclusion guarantee) देण्यासाठी आहे, याचा अर्थ असा की समावेश सूची समितीचे (inclusion list committee) सदस्य असणे इतके मौल्यवान नाही, आणि असे 16 सदस्य आहेत, याचा अर्थ असा की प्रगत उत्पादकांचे कोणतेही मार्केट नाही.

त्यानंतर, मल्टी-स्लॉट MEV कडे वळताना: FOCIL काही समस्या कमी करते, परंतु ते पूर्णपणे सोडवत नाही. सेन्सॉरशिपला विरोध (censorship resistance) आणि MEV वर उपाय या दोन्ही गोष्टी प्रदान करण्यामधील विसंगतीमुळे हे पुन्हा घडते. FOCIL काय करते तर जोपर्यंत व्यवहार शुल्क भरले जाते तोपर्यंत कोणत्याही व्यवहाराचा समावेश करण्याची परवानगी देते, जे काही प्रमाणात मल्टी-स्लॉट MEV सोडवते. येथे मल्टी-स्लॉट MEV म्हणजे जेव्हा एखादा पक्ष सलग दोन ब्लॉक्स नियंत्रित करत असेल तर तो अधिक MEV काढू शकतो.

FOCIL काही समस्या कमी करते कारण ते तुम्हाला तुमचा व्यवहार समाविष्ट करण्याची परवानगी देते. उदाहरणार्थ, जर तुम्हाला कुठेतरी एखाद्या पोझिशनवरील बुडीत कर्ज (bad debt) लिक्विडेट करणारा व्यवहार समाविष्ट करायचा असेल, तर प्रस्तावक तुम्हाला सेन्सॉर करण्याचा प्रयत्न करत असला आणि पुढील ब्लॉकमध्ये तुमच्याकडून MEV काढणार असला तरीही तुम्ही तसे करू शकता.

हे सर्व समस्या का सोडवत नाही याचे कारण म्हणजे प्रतिकूल निवड (adverse selection), ही एक आर्थिक स्थिती आहे जिथे एका व्यक्तीकडे दुसऱ्यापेक्षा जास्त माहिती असते. मल्टी-स्लॉट MEV चे एक उदाहरण म्हणजे दोन ब्लॉक्सवर आर्बिट्रेज (arbitrage) काढणे, जिथे ब्लॉक निर्माता पहिल्या ब्लॉकमध्ये आर्बिट्रेज काढत नाही आणि दुसऱ्या ब्लॉकमध्ये काढतो. काही सैद्धांतिक परिणाम दर्शवतात की दोन्ही स्लॉट्समध्ये आर्बिट्रेज काढण्यापेक्षा ब्लॉक निर्मात्यासाठी हे अधिक फायदेशीर असू शकते. तुम्हाला वाटेल की FOCIL येथे मदत करते, कारण आर्बिट्रेजर्स तत्त्वतः त्यांचा व्यवहार समावेश सूचीमध्ये समाविष्ट करू शकतात आणि त्याद्वारे काही प्रकारचे आर्बिट्रेज घडवून आणू शकतात. जरी हे खरे असले तरी, आर्बिट्रेजर्सनी त्यांचा व्यवहार FOCIL कडे सबमिट करणे हे प्रोत्साहन-सुसंगत (incentive-compatible) नाही, कारण त्यांचा व्यवहार सबमिट होणे आणि ब्लॉक निर्मात्याने कृती करणे या दरम्यान अजूनही 3 सेकंदांचा कालावधी असतो. जर तुम्ही आर्बिट्रेज करण्याचा प्रयत्न करत असाल आणि एखाद्या बाह्य मार्केटमध्ये किंमत सतत बदलत असेल, तर तुम्हाला 3 सेकंद आधी कमिट करायचे नसते, कारण तुमच्याकडे ब्लॉक निर्मात्यापेक्षा खूप कमी माहिती असते, जो तुमच्या नंतर कृती करतो. प्रतिकूल निवड येथे लागू होते कारण निर्मात्याकडे अधिक माहिती असते: जर ते तुमच्यासाठी वाईट असेल, जर त्या 3 अतिरिक्त सेकंदांमध्ये बाह्य मार्केटमधील किंमत तुमच्या विरुद्ध गेली असेल, तर तो तुम्हाला जिंकू देईल, आणि जर स्वतःसाठी जिंकणे चांगले असेल तर तो स्वतःला जिंकू देईल.

त्यामुळे FOCIL मल्टी-स्लॉट MEV चे ते भाग सोडवते जिथे व्यवहारांना प्रतिकूल निवडीचा सामना करावा लागत नाही. ज्या व्यवहारांमध्ये प्रतिकूल निवड असते, त्यांच्यासाठी हे थोडे अधिक गुंतागुंतीचे असते, परंतु ते काही प्रमाणात समस्या कमी करते. तत्त्वतः, हे सध्याच्या परिस्थितीपेक्षा गोष्टी अधिक चांगल्या बनवते, परंतु तरीही थोडे काम करणे बाकी आहे.

पूजा रंजन: खूप छान, हे शेअर केल्याबद्दल खूप खूप धन्यवाद. मला समजते की MEV च्या समस्येवर उपाय शोधण्यासाठी बरेच संशोधन सुरू आहे, त्यामुळे हे जाणून घेणे चांगले आहे की किमान तत्त्वतः हे सध्याच्या परिस्थितीपेक्षा अधिक मदत करणार आहे.

तडजोडी आणि आव्हाने (36:44)

पूजा रंजन: थॉमसने मगाशी IL दुटप्पीपणाबद्दल (equivocation) जे सांगितले, त्यासंबंधी माझा एक प्रश्न आहे. माझ्या लक्षात आले की प्रस्तावाच्या सुरक्षा विचारांच्या विभागात, एकमत जिवंतपणा (consensus liveness), IL दुटप्पीपणा आणि पेलोड निर्मिती यांसारखे बरेच मुद्दे नमूद केले आहेत. तुमच्या मते सर्वात मोठी तडजोड कोणती असेल, किंवा अशी कोणती गोष्ट आहे जिच्यावर अधिक संशोधन करणे आवश्यक आहे आणि ज्यामुळे हा प्रस्ताव जसाच्या तसा पुढील अपग्रेडमध्ये समाविष्ट होण्यापासून रोखला जाऊ शकतो?

थॉमस थियरी: खरे सांगायचे तर, मला वाटते की सुरक्षा विचारांवरील विभाग हा प्रामुख्याने हे दर्शविण्याचा एक मार्ग होता की आम्ही सुरक्षेशी संबंधित चिंतांचा विचार केला आहे आणि त्यांचे निराकरण केले आहे. सुरक्षेबद्दल आपल्याला माहीत नसलेल्या गोष्टींबद्दल अनुत्तरित प्रश्न असण्यापेक्षा हे अधिक आहे. मला वाटत नाही की सुरक्षा विचारांच्या बाबतीत कोणतेही मोठे अडथळे किंवा समस्या आहेत.

तडजोडींबद्दल बोलायचे झाल्यास: जर तुम्ही अगदी संकुचित दृष्टिकोनातून पाहिले, तर हे खरे आहे की FOCIL प्रमाणकांसाठी काही कामे वाढवते, जेव्हा त्यांना समावेशन सूची प्रस्तावित करावी लागते तेव्हा, आणि साक्षांकनकर्त्यांसाठी (attesters), जेव्हा त्यांना ब्लॉक समावेशन सूचीनुसार वैध असल्याची खात्री करण्यासाठी आणखी एक अट तपासावी लागते तेव्हा. हे प्रस्तावकासाठी देखील एक छोटे काम वाढवते, कारण आता त्याला हे सुनिश्चित करावे लागेल की त्याच्या पेलोडमध्ये खरोखरच ILs मधील व्यवहारांचा समावेश आहे. माझ्यासाठी, ही एकमेव तडजोड आहे, आणि ही कामे जड किंवा गुंतागुंतीची नाहीत. IL समितीचा सदस्य फक्त सार्वजनिक मेमपूलवर लक्ष ठेवतो आणि ते पाठवत असलेल्या सूचीमध्ये व्यवहारांचा समावेश करतो. यासाठी कोणत्याही प्रकारच्या कौशल्याची किंवा गुंतागुंतीची आवश्यकता नाही, जे मला वाटते की चांगली गोष्ट आहे. दुसरीकडे, जसे आपण म्हटले, हे काही मोठ्या स्केलिंग सुधारणा आणि प्रोटोकॉलमधील सहभागी आणि कर्तव्ये यांच्यात अधिक चांगले विभाजन उघडू शकते.

मी कदाचित पूर्वग्रहदूषित असेन, पण मला यात मोठ्या तडजोडी दिसत नाहीत. मला नक्कीच वाटते की जेव्हा सेन्सॉरशिप प्रतिकाराचा विचार केला जातो, तेव्हा हे सर्व काही पूर्णपणे बदलून टाकते. आता तुम्हाला सर्व व्यवहारांसाठी, ज्यामध्ये निर्मात्यांद्वारे सेन्सॉर केले जाऊ शकणारे व्यवहार देखील समाविष्ट आहेत, पुढील ब्लॉकमध्ये समाविष्ट करण्यासाठी नेटवर्कपैकी केवळ 15% प्रामाणिक असणे आवश्यक आहे, जी एक खूप मोठी सुधारणा आहे. खरे सांगायचे तर, मला वाटत नाही की तुम्ही तिथे बऱ्याच गोष्टींची तडजोड करत आहात.

पूजा रंजन: हे जाणून आनंद झाला. बहुतेक प्रस्तावांमध्ये आपल्याला असे आढळते की सुरक्षा विचारांच्या विभागात एकतर कोणतीही माहिती नसते किंवा खूप कमी माहिती असते, त्यामुळे त्या भागावर संशोधन केले गेले आहे आणि आपण संभाव्य सुरक्षा विचारांबद्दल जागरूक आहोत हे जाणून घेणे चांगले आहे. भविष्यातील अंमलबजावणी आणि स्वीकृतीसाठी हा कोणताही अडथळा किंवा संभाव्य आव्हान नाही हे जाणून आनंद झाला.

inclusion lists साठी व्यवहार शुल्क यंत्रणा (39:50)

Pooja Ranjan: मला वेबसाइटवरच सापडलेल्या काही खुल्या प्रश्नांबद्दल, व्यवहार शुल्क यंत्रणेविषयी एक प्रश्न विचारायचा आहे. मला जाणून घ्यायचे आहे की यात काही अपडेट आहे का, किंवा inclusion list मध्ये समाविष्ट करण्यासाठी शुल्क आकारण्याचा आणि हे शुल्क वितरित करण्याचा सर्वोत्तम मार्ग कोणता याबद्दल तुम्हाला अधिक काही सांगायला आवडेल का.

Thomas Thiery: आमच्याकडे एक चालू ग्रँट आहे जी विशेषतः यावर आणि IL (inclusion list) समिती सदस्यांना बक्षीस देण्यासाठी प्रोत्साहन यंत्रणांवर लक्ष केंद्रित करत आहे. हे सोपे नाही. हे गुंतागुंतीचे आहे, आणि तुम्ही याकडे कसेही पाहिले तरी, हे खूप मोठे बदल आहेत. इथेरियम वरील शुल्क बदलणे, मग तुम्ही शुल्क बदलत असाल, नवीन जोडत असाल किंवा नवीन निर्गमन जोडत असाल, हे सर्व मोठे बदल आहेत ज्यांचा खूप विचार आणि काळजीपूर्वक अभ्यास करणे आवश्यक आहे. परंतु याचा शोध घेतला जात आहे, आणि उदाहरणार्थ, व्यवहार समाविष्ट करणाऱ्या समिती सदस्यांमध्ये शुल्क वितरित करण्याच्या कल्पना चांगल्या वाटतात. यात एक प्रकारे आपल्याला हवे असलेले गुणधर्म आहेत, कारण जे व्यवहार इतर लोक समाविष्ट करू इच्छित नाहीत ते समाविष्ट करणाऱ्या लोकांना आम्हाला बक्षीस द्यायचे आहे. त्यामुळे आम्ही यावर खूप सखोल विचार करत आहोत, आणि आमच्याकडे एक चालू ग्रँट आहे.

आपण कधी IL समिती सदस्यांना शुल्क द्यायचे का, हा देखील एक प्रश्न आहे, कारण जगभरात विखुरलेल्या लहान सहभागींना बक्षीस देणे खूप कठीण आहे. तुम्हाला Sybil हल्ले नको आहेत, आणि तुम्हाला जास्त स्टेक असलेल्या मोठ्या सहभागींनी IL समिती संचातून इतरांना बाहेर काढावे असेही वाटत नाही. तुम्ही ते कसे रोखता? हे खूप कठीण आहे. त्यामुळे तुम्हाला डिझाइनच्या अनेक बाबी विचारात घ्याव्या लागतील.

अलीकडे माझा एक विचार असा आहे की: जर आपण FOCIL मध्ये गोपनीयतेसारखी काही छान वैशिष्ट्ये जोडली, जेणेकरून व्यवहारांची दिलेली यादी कोणी प्रस्तावित केली हे तुम्हाला खरोखर कळू शकणार नाही, तर कसे राहील? तुम्हाला माहित असते की ती व्यक्ती प्रत्यक्षात IL समिती सदस्य म्हणून निवडली गेली होती, परंतु नक्की कोणत्या यादीचा प्रस्ताव कोणी दिला हे तुम्हाला माहित नसते, त्यामुळे तुम्ही IL समिती सदस्यांना त्यांच्या ILs मधील व्यवहारांच्या संचाशी जोडू शकत नाही. जर आपण असे करू शकलो, आणि IL समितीची भूमिका एक प्रकारे ऐच्छिक (opt-in) ठेवली, तर आपल्याकडे कदाचित प्रोटोकॉलमध्ये प्रामाणिक सहभागी असतील, जे परोपकारी वर्तनावर अवलंबून असतील, आणि कदाचित आपल्याला शुल्क यंत्रणा स्थापित करण्याची अजिबात गरज भासणार नाही. हा अगदी अलीकडचा, वैयक्तिक मतावर आधारित विचार आहे, आणि सध्या यावर खूप शोध घेतला जात आहे. या सर्व "FOCIL चे भविष्य" यावरील चर्चा आहेत; त्या सध्याच्या EIP मध्ये समाविष्ट करणे अपेक्षित नाही.

Julian Ma: यात भर घालण्यासाठी, तो शेवटचा भाग देखील खूप महत्त्वाचा आहे: अंमलबजावणी करणे सोपे व्हावे यासाठी EIP-7805 मध्ये कोणत्याही व्यवहार शुल्क यंत्रणेचा समावेश नाही. सेन्सॉरशिप प्रतिरोधक गुणधर्म प्रदान करण्याचा हा मुळात सर्वात लहान संभाव्य मार्ग आहे, परंतु तो खूप विस्तारण्यायोग्य आहे. आम्ही त्याकडे लक्ष देत आहोत. थॉमसने समाविष्ट करणाऱ्यांसाठी (includers) आणि प्रस्तावकांसाठी स्वतंत्र व्यवहार शुल्कावर बरेच काम केले आहे. त्यानंतर, थॉमसने नमूद केल्याप्रमाणे, नेदरमाइंड मधील एका उत्कृष्ट संशोधकासोबत आमची एक चालू ग्रँट आहे जो FOCIL साठी व्यवहार शुल्क यंत्रणा तयार करण्यावर काम करत आहे, आणि हे खूप आशादायी आहे. आणि शेवटी, AUCIL नावाच्या FOCIL च्या एका प्रकारासाठी व्यवहार शुल्क यंत्रणेवर काम केले गेले आहे, जे सरिश्त वाधवा, फॅन झांग आणि कार्तिक नायक यांनी FOCIL च्या अनेक लेखकांसह प्रस्तावित केलेले लिलाव-आधारित inclusion list डिझाइन आहे, जे inclusion list समिती सदस्यांना प्रोत्साहन देण्याचे मार्ग शोधते.

लुईसच्या आधीच्या मुद्द्यानुसार, प्रोत्साहन देणे हे inclusion lists कशा तयार केल्या जातात यावर खूप अवलंबून असते. याचा अर्थ असा की inclusion list समिती सदस्यांनी कसे वागावे याचा एक विशिष्ट दृष्टिकोन प्रोटोकॉलला द्यायचा आहे. सामान्यतः याचा अर्थ असा होतो की काही विशिष्ट सहभागींनी वेगवेगळ्या गोष्टी कराव्यात अशी त्याची इच्छा असते. उदाहरणार्थ, समिती सदस्यांमध्ये अजूनही काही वेगळे वर्तन असावे यासाठी, ते समिती सदस्यांना क्रमवारी लावू शकते आणि सहसंबंधित समतोल (correlated equilibrium) द्वारे त्यांना विशिष्ट व्यवहार नियुक्त करू शकते. त्यामुळे हा सध्याच्या प्रस्तावाचा भाग नाही, परंतु आम्ही नक्कीच यावर विचार करत आहोत, आणि हे FOCIL च्या विस्तारक्षमतेच्या कक्षेत बसते.

Pooja Ranjan: अरे, हे मनोरंजक आहे. त्यामुळे सध्याच्या FOCIL वैशिष्ट्यांमध्ये वाढ करण्यासाठी आपण भविष्यात काही पूरक प्रस्तावांची वाट पाहिली पाहिजे.

समावेशन सूचीचा आकार (44:16)

पूजा रंजन: माझा आणखी एक प्रश्न आहे. मला खात्री नाही की हा सध्याच्या प्रस्तावाचा भाग असावा की नाही, परंतु IL च्या आकाराबद्दल काही अपडेट आहे का हे जाणून घेण्याची मला उत्सुकता आहे. अतिरिक्त बँडविड्थचा वापर टाळण्यासाठी समावेशन सूचीचा आकार मर्यादित असण्याची शक्यता आहे. समावेशन सूचीचा इष्टतम आकार कसा ठरवता येईल यावर आपल्याकडे काही पुढील संशोधन किंवा अपडेट्स आहेत का?

थॉमस थियरी: आमच्याकडे आता स्पेक (spec) मध्ये एक निश्चित आकार आहे, आणि तो काही काळापासून तिथे आहे: 8 किलोबाइट्स. आम्ही ते किलोबाइट्समध्ये ठेवले आहे कारण FOCIL आणि ILs खरोखरच बँडविड्थ वापरतात, आणि तेवढेच आहे. जर तुम्ही मध्यक व्यवहार आकार (median transaction size) विचारात घेतला, तर आपल्याला प्रति IL सुमारे 40 व्यवहार मिळतात, आणि जर सर्व व्यवहार अद्वितीय असतील, तर ते सुमारे 640 व्यवहार आहेत जे सर्व 16 समिती सदस्यांमध्ये एकत्र केले जाऊ शकतात.

नेमक्या इष्टतम आकारावर खूप संशोधन करण्याची गरज आहे की नाही हे मला माहीत नाही. आम्ही जे ठरवले: 16 गुणिले 8 किलोबाइट्स हा मुळात एका ब्लॉबचा आकार आहे, त्यामुळे एकत्रितपणे ही खूप मोठी बँडविड्थ नाही. आणि ILs मधील व्यवहारांचे संयोजन एका ब्लॉकपेक्षा मोठे असल्यामुळे, मला वाटत नाही की आपल्याला तिथे काही समस्या येतील.

भविष्यासाठी, तुम्ही IL चा आकार वाढवू शकता, परंतु तुम्ही IL समिती सदस्यांची संख्या वाढवण्याचाही विचार करू शकता. जर नेटवर्कच्या बहुतांश भागाने सेन्सॉरशिप सुरू करण्याचे ठरवले, तर यामुळे तुम्हाला एक प्रामाणिक IL समिती सदस्य मिळण्याची अधिक शक्यता असते. त्यामुळे आपण हे देखील करू शकतो. सध्या तरी, 16 ही संख्या पूर्णपणे योग्य आणि पुरेशी वाटत आहे, परंतु जर सेन्सॉरशिप खूपच वाढली, किंवा आपल्याला अधिक कारवाई करण्याची आवश्यकता भासली, तर भविष्यात तुम्ही नक्कीच या पॅरामीटर्समध्ये बदल करू शकता.

स्वीकृतीचा मागोवा घेण्यासाठी मेट्रिक्स (46:39)

पूजा रंजन: येथे फक्त एक फॉलो-अप: या प्रस्तावाची स्वीकृती किंवा यश समजून घेण्यासाठी आपण मागोवा घेऊ शकू असे कोणतेही मेट्रिक्स तुमच्या लक्षात आहेत का?

ज्युलियन मा: हा एक उत्तम प्रश्न आहे. मी पटकन उत्तर देतो आणि मग थॉमसकडे सूत्रे सोपवतो. काही सोपे मेट्रिक्स म्हणजे किती समावेश सूची (inclusion lists) प्रस्तावित केल्या आहेत ज्या रिक्त नाहीत. आणि तुम्ही डॅशबोर्ड्सचा विचार करू शकता, जसे की टोनी वॉरस्टॅटर (Toni Wahrstätter) ची ".pics" मालिका, जिथे कदाचित अधिक विविधता असेल, या समावेश सूचींना काही गुणवत्ता मोजमाप नियुक्त केले जाईल. तत्त्वतः, सेन्सॉरशिपला प्रतिकार करण्यासाठी प्रति स्लॉट फक्त एका व्यक्तीने योग्य समावेश सूची तयार करणे आवश्यक आहे.

मला वाटते की हा इतका महत्त्वाचा मुद्दा आहे की FOCIL लवकर लागू करणे महत्त्वाचे आहे, कारण आता आपण अशा एका जादुई स्थितीत आहोत जिथे ब्लॉक निर्माते जास्त सेन्सॉर करत नाहीत आणि प्रमाणक जास्त सेन्सॉर करत नाहीत. मी म्हणेन की हे खूप नाजूक आहे. आतापर्यंत, ब्लॉक निर्माते बऱ्याच काळापासून सेन्सॉर करत आहेत, आणि जर आपण आता FOCIL आणले, तर आपल्याकडे हे डीफॉल्ट बनवण्याची शक्यता आहे की हे सर्व प्रमाणक ते स्वीकारतील आणि अर्थपूर्ण समावेश सूची तयार करतील. कारण ब्लॉक निर्माते सेन्सॉर करत नाहीत, त्यामुळे येथे कोणतीही बाजारातील अस्थिरता निर्माण होत नाही. जर आपण निर्मात्यांमध्ये सेन्सॉरशिप येईपर्यंत वाट पाहिली, तर FOCIL आणणे खूप कठीण होईल, आणि मला वाटते की स्वीकृती मोजण्यासाठी वापरले जाणारे सर्व मेट्रिक्स खूपच वाईट असतील.

थॉमस थियरी: पाहण्यासारखे आणखी एक प्रमुख मेट्रिक म्हणजे सार्वजनिक मेमपूल व्यवहारांसाठी समावेशातील विलंब. तुम्ही सार्वजनिक मेमपूलमध्ये प्रलंबित असलेले सर्व व्यवहार घेता आणि ते किती वेगाने समाविष्ट केले जातात ते पाहता. जर FOCIL ने काम केले, तर ते सर्व पुढील ब्लॉकमध्ये समाविष्ट केले जातील. जर ते तसे झाले नाहीत, तर याचा अर्थ प्रमाणकांचा एक मोठा भाग सेन्सॉर करत आहे. त्यामुळे आपण पाहू शकणारे दुसरे मेट्रिक म्हणजे कोण सेन्सॉर करत आहे, आणि नेटवर्कचा किती भाग सेन्सॉर करत आहे. याचा मागोवा ठेवण्यासाठी आमच्याकडे डॅशबोर्ड आणि अतिशय पारदर्शक मेट्रिक्स असतील, कारण मुळात FOCIL ने हेच करणे अपेक्षित आहे. जर सार्वजनिक व्यवहार पुढील ब्लॉकमध्ये समाविष्ट केले गेले नाहीत, तर याचा अर्थ नेटवर्कचा एक खूप मोठा भाग प्रत्यक्षात या व्यवहारांना सेन्सॉर करत आहे.

पूजा रंजन: खूप मनोरंजक. त्यामुळे कदाचित हे संशोधकांसाठी काहीतरी आहे: अपग्रेड्ससाठी एक संभाव्य विशलिस्ट, की जेव्हा जेव्हा एखादा प्रस्ताव नेटवर्क अपग्रेडमध्ये समाविष्ट केला जातो तेव्हा विकासकांनी डॅशबोर्ड आणि मेट्रिक्स ट्रॅकर्स सामायिक केले पाहिजेत.

क्लायंट अंमलबजावणी स्थिती (49:11)

पूजा रंजन: ज्युलियनने नमूद केल्याप्रमाणे, या प्रस्तावाची शक्य तितक्या लवकर अंमलबजावणी करणे आवश्यक असू शकते. क्लायंटच्या अंमलबजावणीबाबत आपण सध्या कोणत्या टप्प्यावर आहोत हे जाणून घेण्याची मला उत्सुकता आहे, कारण मला आठवते की मागील टेस्टनेट कॉलमध्ये परितोषने डेव्हनेट्सच्या मदतीने काही सपोर्ट जोडण्याचा उल्लेख केला होता. तर त्याबाबत आपली काय स्थिती आहे?

थॉमस थियरी: आपण खूप चांगली प्रगती करत आहोत. सर्वात आधी, लोकांनी FOCIL च्या अंमलबजावणीचा भाग ज्या प्रकारे स्वीकारला आहे ते पाहणे खूप छान वाटले, कारण मी डेव्हलपर नाही, मी एक संशोधक आहे. मी सुरुवातीपासूनच डेव्हलपर्ससोबत काम करत आहे, परंतु क्लायंट्समध्ये गोष्टींची अंमलबजावणी करणारा मी नाही.

ज्यांनी याचे नेतृत्व केले, ते तिघे जण: आपल्याकडे प्रिझम कडून टेरेन्स आहे, आणि जिहून, जो टेरेन्सला प्रिझमवर खूप मदत करत आहे पण त्याने गेथ वरही काम केले आहे. त्यामुळे आता आपल्याकडे प्रिझम आणि गेथसाठी एक कार्यरत डेव्हनेट आहे, जे खूप छान आहे, आणि त्यावर अनेक चाचण्या सुरू आहेत. आम्ही आता FOCIL ला Dora एक्सप्लोररवर दाखवण्याचा आणि दृश्यमान करण्याचा प्रयत्न करत आहोत. त्यानंतर जेकब आहे, ज्याने लाइटहाऊस आणि रेथ वर काम केले आहे, आणि मला माहित आहे की तिथे अजूनही काही प्रयत्न सुरू आहेत. लोडस्टार अलीकडे खूप सक्रिय आहे; मला वाटते की ते कार्यरत डेव्हनेट तयार करण्याच्या अगदी जवळ आहेत. आज आम्हाला नेदरमाइंड कडून काही बातम्या मिळाल्या की त्यांच्याकडे एक प्रोटोटाइप आहे, जे खूप छान आहे. मला असे वाटते की मी काहींना विसरत आहे... निंबस देखील सामील होत आहे, असे जिहून म्हणतो. हे खरोखरच छान आहे.

एकंदरीत, आपण अधिकाधिक डेव्हनेट्स तयार आणि लाईव्ह करत आहोत, स्थानिक डेव्हनेट्स, आणि अंमलबजावणी आणि सहमती स्तर क्लायंट्समध्ये अधिकाधिक कॉम्बिनेशन्स तयार करत आहोत. खरोखरच खूप चांगली प्रगती झाली आहे, आणि हे पाहणे छान आहे, कारण आपल्या सर्वांना माहित आहे की पेक्ट्रा येत असल्यामुळे डेव्हलपर्स आता खूप व्यस्त आहेत, आणि आधीच PeerDAS आणि इतर गोष्टींवर काम करत आहेत. इथेरियमवरील लोक एकंदरीत सेन्सॉरशिपच्या प्रतिकाराबद्दल किती काळजी घेतात हे पाहणे खरोखरच खूप छान आहे. ज्या बहुतांश टीम्सशी मी विशेषतः संपर्क साधला नव्हता, त्या स्वतःहून या प्रयत्नात सामील झाल्या आहेत आणि आता डेव्हनेट्स आणि टेस्टिंगच्या दिशेने काम करत आहेत.

पूजा रंजन: ही माहिती शेअर केल्याबद्दल धन्यवाद. मी डेव्हनेट्सवरील अपडेट्स फॉलो करण्यासाठी उत्सुक आहे. या डेव्हनेटचे किती इटरेशन्स असतील याची मला खात्री नाही, पण ते प्रत्यक्षात येताना पाहण्यासाठी मी उत्सुक आहे. मला दिसतेय की जस्टिनचा इथे एक प्रश्न आहे. जस्टिन, कृपया विचार.

फुसाका किंवा ग्लॅमस्टरडॅममध्ये FOCIL? (52:07)

जस्टिन: ठीक आहे, यासाठी तयार राहा. तुम्ही एक अतिशय चांगला मुद्दा मांडलात की सेन्सॉरशिपला सामोरे जाण्याची सर्वोत्तम वेळ सेन्सॉरशिप होण्यापूर्वीची असते, बरोबर? तर: फुसाकामध्ये FOCIL, की ते ग्लॅमस्टरडॅमची वाट पाहू शकते? आणि एक डेव्हलपर म्हणून मी कशाचा पुरस्कार केला पाहिजे?

थॉमस थियरी: आम्ही PR उघडली आहे, आणि ती मर्ज केली गेली आहे, ज्यामध्ये FOCIL चा फुसाकासाठी प्रस्ताव दिला जात आहे. आम्हाला वाटते की ते फुसाकामध्ये गेले पाहिजे. यामागील एक कारण असे आहे की काही क्लायंट्सनी आधीच त्यावर काम सुरू केले आहे, आणि त्यांना फारशा अडचणी आलेल्या नाहीत. हे इतर प्रस्तावांसारखे नाही ज्यांची अंमलबजावणी करणे खूप कठीण असते आणि ज्यामध्ये खूप जास्त काम असते. आणि हे फार वादग्रस्त देखील नाही. मला वाटत नाही की कोणीही सेन्सॉरशिप प्रतिकाराच्या विरोधात बोलत आहे, आणि प्रत्येकाला असे वाटते की शक्य तितक्या लवकर याचा समावेश करणे आवश्यक आहे. त्यामुळे मी फुसाकाची निवड करेन.

ते वाट पाहू शकते की नाही हे मला माहीत नाही. प्रस्ताव आणि अपग्रेड्स नेहमीच वाट पाहू शकतात. मला फक्त अशा जगाला टाळायचे आहे जिथे हे बदल लागू करणे सोपे नसेल. गोष्टी खूप लवकर बदलू शकतात. जसे आपण पाहिले, ते उलट घडले: काही महिन्यांपूर्वी, एका मुख्य निर्मात्याने अचानक सेन्सॉर करणे थांबवले. आम्ही विचारले का, आणि ते म्हणाले, "होय, आम्ही फक्त तसे न करण्याचे ठरवले." त्या बाबतीत ते चांगले होते, कारण ते चांगल्या बाजूने होते, परंतु ते पूर्णपणे उलट होऊ शकते, आणि मग आपल्याकडे काही व्यवहारांचे सेन्सॉर करणारे दोन निर्माते असू शकतात, आणि आपण पुन्हा एका अत्यंत वाईट स्थितीत असू.

दुसरी गोष्ट जी मला नमूद करायची आहे, कारण मला वाटते की ती महत्त्वाची आहे: जर आपण बोललेल्या काही गोष्टींकडे गेलो, जसे की APS, जिथे आपण काम केलेल्या काही डिझाईन्ससह अटेस्टर आणि प्रस्तावक प्रत्यक्षात वेगळे करू शकता, तर त्याआधी आपल्याकडे FOCIL असणे आवश्यक आहे, आणि FOCIL काम करत आहे हे आपल्याला माहीत असणे आवश्यक आहे. FOCIL आपला उद्देश पूर्ण करत आहे, जो इथेरियमच्या सेन्सॉरशिप प्रतिकार गुणधर्मांची देखभाल आणि सुधारणा करणे हा आहे, याची खात्री करण्यासाठी आपल्याला मुख्यनेटवर सहा महिने, एक वर्षासाठी FOCIL ची आवश्यकता आहे. त्यामुळे आणखी एक निकड, किमान माझ्यासाठी, ही आहे की जर आपल्याला अटेस्टर्सना टायमिंग गेम्स आणि APS सह आपण ज्या इतर काही चिंता दूर करू इच्छितो त्यापासून वाचवायचे असेल, तर आपल्याला शक्य तितक्या लवकर FOCIL ची आवश्यकता आहे.

पूजा रंजन: कधीकधी हे पाहणे दुःखद असते जेव्हा पुढील किंवा जवळच्या अपग्रेडसाठी प्रस्ताव निवडले जात नाहीत, परंतु एका अपग्रेडमध्ये केवळ काहीच प्रस्तावांचा समावेश केला जाऊ शकतो. प्रस्तावाच्या सादरीकरणामागे, प्रस्तावाच्या तयारीमागे, तसेच त्यामध्ये जाणाऱ्या चाचणीमागे केल्या जाणाऱ्या सर्व कठोर परिश्रमांचे मी खरोखर कौतुक करते. त्यामुळे इथेरियम इकोसिस्टमसाठी तुम्ही करत असलेल्या सर्व कामाबद्दल तुमचे खूप खूप आभार.

रॅपिड फायर (55:18)

पूजा रंजन: आपण संपवण्यापूर्वी, आपल्याकडे एक छोटा रॅपिड फायर राऊंड आहे. यासाठी एकच अट आहे की उत्तर एका शब्दात किंवा एका वाक्यात असावे, आणि आपण हे टायमरवर करण्याचा प्रयत्न करू, कदाचित प्रत्येकी 30 सेकंद. जर तुम्ही तयार असाल, तर आपण पुढे जाऊया आणि ज्युलियनपासून सुरुवात करूया. सध्या ब्लॉकचेन संशोधनातील सर्वात कठीण समस्या कोणती आहे?

ज्युलियन मा: मी जास्त मीम-सारखे उत्तर देणार नाही, त्यामुळे मी याचे गांभीर्याने उत्तर देईन. मी म्हणेन की सर्वात कठीण समस्या स्टेकिंगचे भविष्य ही आहे: स्टेकिंगच्या भविष्याचा अर्थ काय आहे, सेवा पुरवठादार कोणती भूमिका बजावतात, त्यांना त्यासाठी कसा मोबदला दिला जातो आणि त्यांचा एकमेकांशी कसा संबंध आहे.

पूजा रंजन: ब्लॉकचेनचा असा कोणता युज केस आहे ज्याचा पुरेसा शोध घेतला गेला नाही?

ज्युलियन मा: मी म्हणेन FOCIL.

पूजा रंजन: आज इथेरियमसाठी सर्वात मोठा सुरक्षा धोका कोणता आहे?

ज्युलियन मा: मी प्रामाणिकपणे सांगेन की सेन्सॉरशिप प्रतिरोध येथे खूप महत्त्वाचा आहे, कारण मल्टी-ब्लॉक MEV सारख्या गोष्टींमुळे मोठे सुरक्षा धोके निर्माण होऊ शकतात, उदाहरणार्थ स्तर २ (l2) साठी.

पूजा रंजन: MEV कमी केले पाहिजे, स्वीकारले पाहिजे की या दोन्हींच्या मधले काहीतरी असावे?

ज्युलियन मा: मी येथे Flashbots च्या मताशी मोठ्या प्रमाणावर सहमत आहे, की त्याचे लोकशाहीकरण केले पाहिजे, याचा अर्थ असा की जिथे आवश्यक असेल तिथे ते जास्तीत जास्त वाढवले पाहिजे आणि ॲप्लिकेशन स्तरावर ते कमी केले पाहिजे.

पूजा रंजन: विकेंद्रीकरणासाठी तडजोड करणे नेहमीच योग्य असते का?

ज्युलियन मा: त्यासाठी तडजोड करणे सहसा योग्य असते.

पूजा रंजन: इथेरियमने जगाला दिलेला सर्वात मोठा नाविन्यपूर्ण शोध कोणता आहे?

ज्युलियन मा: येथे मी डिजिटल मालमत्ता अधिकारांवरील डेव्हकॉनमधील (Devcon) माईक न्यूडरच्या भाषणाचा संदर्भ देऊ इच्छितो. मी म्हणेन की सेन्सॉरशिप-प्रतिरोधक डिजिटल मालमत्ता अधिकार जे खरोखरच जग बदलत आहेत.

पूजा रंजन: खूप खूप धन्यवाद, खूप छान उत्तर दिले. माझ्या प्रश्नांचा पुढचा संच थॉमससाठी आहे. तर, जर इथेरियम अस्तित्वात नसते, तर तुम्ही कोणत्या ब्लॉकचेनवर काम करत असता?

थॉमस थियरी: मला वाटते की मी खूप मीम-सारखे उत्तर देईन, आणि ज्युलियनने माझी थोडी फिरकी घेतली कारण मला वाटले होते की तोही असेच करेल. ती ब्लॉकचेन FOCIL असेल.

पूजा रंजन: ब्लॉकचेनचा सर्वात जास्त गाजावाजा झालेला (overhyped) युज केस कोणता आहे?

थॉमस थियरी: FOCIL शिवाय कोणत्याही युज केसचा गाजावाजा करणे योग्य नाही.

पूजा रंजन: इथेरियमने लवकरात लवकर सुधारण्याची गरज असलेली एक गोष्ट कोणती?

थॉमस थियरी: सेन्सॉरशिप प्रतिरोध, FOCIL सह.

पूजा रंजन: विकेंद्रीकरण वर्णन करण्यासाठी एक शब्द?

थॉमस थियरी: FOCIL.

पूजा रंजन: तुम्हाला वाटते का की इथेरियम स्केलेबिलिटीची समस्या पूर्णपणे सोडवेल?

थॉमस थियरी: FOCIL सह इथेरियम, होय.

पूजा रंजन: स्तर १ (l1) स्केलिंग की स्तर २ (l2) स्केलिंग, कोण जिंकेल?

थॉमस थियरी: अनंत स्तर, सर्व FOCIL सह.

पूजा रंजन: खूप छान, खूप खूप धन्यवाद, थॉमस. या सर्व प्रश्नांची उत्तरे दिल्याबद्दल धन्यवाद. आपण आता संपवत असताना, मी तुम्हाला ही संधी देऊ इच्छिते: जर तुमच्याकडे या प्रस्तावाबद्दल समुदायासाठी, किंवा सर्वसाधारणपणे इथेरियम समुदायासाठी कोणताही संदेश असेल तर तो सांगा.

समुदायासाठी संदेश (58:08)

थॉमस थियरी: खरं तर, हा एक अतिशय महत्त्वाचा मुद्दा आहे, कारण आमच्यात नेहमीच सक्रिय चर्चा होत असतात आणि हे सर्व डिस्कॉर्ड् वर सार्वजनिक असते. सुरुवातीला हे सर्व सार्वजनिक करण्यासाठी आग्रह धरला गेला होता आणि लोक खरोखरच तसे करत आहेत, त्यामुळे मला खूप आनंद झाला आहे. तुम्ही सार्वजनिक Eth R&D डिस्कॉर्ड् वरील inclusion-list चॅनेलवर चर्चा आणि प्रगतीचा मागोवा घेऊ शकता. सध्या हे सर्व प्रामुख्याने तिथेच घडत आहे. त्यानंतर तुम्ही आमच्याशी ट्विटर्, टेलिग्राम् किंवा इतर कुठेही संपर्क साधू शकता. मोकळेपणाने संपर्क करा.

आम्ही जितक्या जास्त लोकांशी बोलू आणि त्यांना सामावून घेऊ, तितके डिझाइन आणि अंमलबजावणी अधिक चांगली होईल. त्यामुळे जर तुम्ही कोणत्याही प्रकारे मदत करू शकत असाल, तर संपर्क साधा आणि आम्हाला सर्व बाजूंनी, अगदी संशोधनाच्या बाजूनेही मदत करायला आवडेल. मला वाटते की, ज्यांना FOCIL च्या भविष्यावर काम करायचे आहे अशा लोकांसोबत काम करणे आमच्यासाठी अधिक योग्य ठरेल. आम्ही गोपनीयतेचा उल्लेख केला, आम्ही व्यवहार शुल्क यंत्रणांचा उल्लेख केला आणि आम्ही ब्लॉबसाठी FOCIL वर देखील खूप लक्ष केंद्रित करणार आहोत. या सर्व गोष्टींसाठी लोक आणि संशोधन प्रयत्नांची आवश्यकता आहे. जर तुम्हाला स्वारस्य असेल, तर संपर्क साधा. आम्हाला आमंत्रित केल्याबद्दल खूप खूप धन्यवाद, आणि तुम्ही इथेरियम साठी करत असलेल्या सर्व कामांबद्दलही धन्यवाद.

ज्युलियन मा: त्यात भर घालण्यासाठी, मला आशा आहे की आम्ही काही लोकांना FOCIL बद्दल उत्साही केले असेल. जर तुम्ही उत्साही असाल, तर कृपया आम्हाला कळवा. आणि जर तुमचे अजूनही काही प्रश्न असतील, तर आम्हाला त्यांची उत्तरे द्यायला आवडेल, आणि आशा आहे की आम्ही तुम्हाला पटवून देऊ शकू की FOCIL हाच खरोखर योग्य मार्ग आहे. खूप खूप धन्यवाद. इथे येऊन खरोखरच खूप आनंद झाला, आणि हे सत्र आयोजित केल्याबद्दल धन्यवाद. आणि अर्थातच, उपस्थित राहिल्याबद्दल सर्वांचे आभार.

समारोपाचे शब्द (59:52)

पूजा रंजन: धन्यवाद. आजच्यासाठी एवढेच. आज आमच्यासोबत सामील झाल्याबद्दल आणि EIP-7805 वर त्यांचे विचार सामायिक केल्याबद्दल थॉमस आणि ज्युलियन यांचे खूप खूप आभार. सर्व सहभागींचे आभार; तुमचे प्रश्न उत्साहवर्धक आणि माहितीपूर्ण आहेत. पाहिल्याबद्दल धन्यवाद. जर तुम्हाला हा संवाद आवडला असेल, तर नक्की लाईक करा, सबस्क्राईब करा आणि हा भाग तुमच्या इतर इथेरियम उत्साही मित्रांसोबत शेअर करा. आम्ही PEEPanEIP वर तुमच्यासाठी आणखी EIPs आणि संशोधनातील प्रगती घेऊन येऊ. पुढच्या वेळेपर्यंत, ज्ञानाने समृद्ध राहा आणि Ethereum Cat Herders सोबत इथेरियममध्ये शोध घेत राहा. तुमचा उरलेला दिवस आनंदात जावो.