بالأمس، أثناء بحثي في GRVT، قضيت قرابة ساعة أتصفح وثائق الـAPI.
كثيرون يدرسون منصات التداول، وأول شيء يلفت انتباههم عادةً سرعة التنفيذ والرسوم، وما هي العملات المدرجة.
كنت أفعل ذلك أيضًا.
لكن بعد أن تعرضت لعدة خسائر، بدأت أنظر أولاً إلى شيء آخر—الصلاحيات.
لأنني كلما ازددت قناعة، بأن مدى أمان المنصة لا يتحدد بما تروّجه من تصريحات، بل بما تمنحه من “السلطة” لمن.
توجد في GRVT تفاصيل جعلت انطباعًا عميقًا لدي.
فصلاحيات الـAPI فيها ليست مرتبطة مباشرةً بالحساب كاملًا، بل تُربط بطبقة حساب التداول، ولا تصبح سارية إلا بعد ربطها بعنوان محدد على شبكة الإيثيريوم.
كما توفر الجهة الرسمية نمطين: في الوضع الآمن يحتفظ المستخدم بالمفتاح الخاص بنفسه؛ وفي الوضع المريح يقوم المتصفح بتوليد المفتاح، لكن المنصة تذكر بوضوح أنها لن تقوم بحفظه.
قد يعتقد كثيرون عند قراءة ذلك: أليس هذا هو الـAPI؟
لكن اهتمامي كان بأمر آخر.
هي في الواقع ما زالت تؤكد على نقطة واحدة: يمكن تقسيم الصلاحيات، ولا يجوز أن يكون مفهوم “من يملك التحكم” غامضًا.
في السابق، كان لدى كثير من المنصات عبر مفتاح API واحد تقريبًا القدرة كاملة؛ وإذا تسرب المفتاح، فقد تكون العواقب خطيرة جدًا.
أما تصميم GRVT، فقد جعلني على الأقل أرى أنها بذلت قدرًا كبيرًا من التفكير عند حدود الصلاحيات—أرادت تفكيك القدرات المختلفة لإدارتها بشكل منفصل، بدل جمعها كلها معًا.
طبعًا، لن “أقدّس” أي تصميم.
سواء كانت بيئة المتصفح آمنة، وما إذا كان جهازك مصابًا ببرمجيات خبيثة، وما إذا كان المستخدم قد جهّز نسخة احتياطية للمفتاح—هذه المخاطر في النهاية ستظل على عاتق المستخدم، ولا يمكن لأي منصة أن تعوّض ذلك بالكامل.
لذلك أشعر أكثر فأكثر بأن علامة النضج الحقيقي في مجال التشفير ليست أن تتحمل المنصة كل شيء عن المستخدم، بل أن تشرح المنصة كل صلاحية وكل مسؤولية بشكل واضح ومفصل بما يكفي.
هل تُعد هذه المنظومة من GRVT أفضل حل فعلاً؟ ما يزال يتعين التحقق من ذلك مع مرور الوقت.
لكن على الأقل، جعلتني أبدأ بإعادة التفكير في سؤال واحد.
ربما لا تكون منصات التداول في المستقبل هي من تتنافس على “الوظائف” أكثر، بل على من يفهم “الصلاحيات” بعمق أكبر.
@grvt_io #grvt
كثيرون يدرسون منصات التداول، وأول شيء يلفت انتباههم عادةً سرعة التنفيذ والرسوم، وما هي العملات المدرجة.
كنت أفعل ذلك أيضًا.
لكن بعد أن تعرضت لعدة خسائر، بدأت أنظر أولاً إلى شيء آخر—الصلاحيات.
لأنني كلما ازددت قناعة، بأن مدى أمان المنصة لا يتحدد بما تروّجه من تصريحات، بل بما تمنحه من “السلطة” لمن.
توجد في GRVT تفاصيل جعلت انطباعًا عميقًا لدي.
فصلاحيات الـAPI فيها ليست مرتبطة مباشرةً بالحساب كاملًا، بل تُربط بطبقة حساب التداول، ولا تصبح سارية إلا بعد ربطها بعنوان محدد على شبكة الإيثيريوم.
كما توفر الجهة الرسمية نمطين: في الوضع الآمن يحتفظ المستخدم بالمفتاح الخاص بنفسه؛ وفي الوضع المريح يقوم المتصفح بتوليد المفتاح، لكن المنصة تذكر بوضوح أنها لن تقوم بحفظه.
قد يعتقد كثيرون عند قراءة ذلك: أليس هذا هو الـAPI؟
لكن اهتمامي كان بأمر آخر.
هي في الواقع ما زالت تؤكد على نقطة واحدة: يمكن تقسيم الصلاحيات، ولا يجوز أن يكون مفهوم “من يملك التحكم” غامضًا.
في السابق، كان لدى كثير من المنصات عبر مفتاح API واحد تقريبًا القدرة كاملة؛ وإذا تسرب المفتاح، فقد تكون العواقب خطيرة جدًا.
أما تصميم GRVT، فقد جعلني على الأقل أرى أنها بذلت قدرًا كبيرًا من التفكير عند حدود الصلاحيات—أرادت تفكيك القدرات المختلفة لإدارتها بشكل منفصل، بدل جمعها كلها معًا.
طبعًا، لن “أقدّس” أي تصميم.
سواء كانت بيئة المتصفح آمنة، وما إذا كان جهازك مصابًا ببرمجيات خبيثة، وما إذا كان المستخدم قد جهّز نسخة احتياطية للمفتاح—هذه المخاطر في النهاية ستظل على عاتق المستخدم، ولا يمكن لأي منصة أن تعوّض ذلك بالكامل.
لذلك أشعر أكثر فأكثر بأن علامة النضج الحقيقي في مجال التشفير ليست أن تتحمل المنصة كل شيء عن المستخدم، بل أن تشرح المنصة كل صلاحية وكل مسؤولية بشكل واضح ومفصل بما يكفي.
هل تُعد هذه المنظومة من GRVT أفضل حل فعلاً؟ ما يزال يتعين التحقق من ذلك مع مرور الوقت.
لكن على الأقل، جعلتني أبدأ بإعادة التفكير في سؤال واحد.
ربما لا تكون منصات التداول في المستقبل هي من تتنافس على “الوظائف” أكثر، بل على من يفهم “الصلاحيات” بعمق أكبر.
@grvt_io #grvt