У этого стандарта есть пояснение:
A general purpose bus for sharing EL triggered requests with the CL.Я понимаю это, как
Универсальная шина для обмена сообщениями Execution layer c Consensus Layer.▫️Зачем?
Сейчас этот самый связный стандарт с другими:
- EIP-6110. Изменение механизма депозита для запуска валидатора
- EIP-7002. Изменение механизма снятия депозита с которым запускался валидатор
- EIP-7251. Увеличение нижней границы депозита валидатора с 32 ETH до специальной переменной
EIP-6110 мы разбирали в прошлом посте, два последних нам еще предстоит разобрать. Но даже на основании названий можно выделить общие черты. Все EIP завязаны на системный контракт депозита с последующим вызовом уровня консенсуса для передачи ему информации (о депозите или снятии активов).
EIP-7685 предвидит увеличение подобных процессов и уже сейчас предлагает унифицировать коммуникацию между EL и CL.
▫️Каким образом?
Предлагается взять за основу стандарт EIP-2718: Typed Transaction Envelope и реализовать общение через специальный тип запроса (request). На сколько мне удалось понять, будет использоваться уже существующий механизм кодирования транзакции RLP для кодирования данных запроса. Сами данные должны быть просты
requests = request_type ++ request_data. Тип запроса - это депозит, снятие и так далее, плюс данные для передачи на уровень консенсуса. Уровень консенсуса будет доставать данные запроса из специального поля в заголовке блока, который будет определять хеш такого запроса.▫️Ordering
Важной составляющей является порядок таких запросов. Так как в рамках одного блока может быть несколько депозитов и несколько снятий, то их порядок ни в коем случае не должен быть нарушен, иначе это может привести к нежелательным последствиям, когда снятие невозможно, потому что не был проведен депозит. Учитывать системное время в рамках одного блока трудно в реализации, поэтому выбран вариант упорядочивания по типу, то есть сначала могут идти запросы типа депозиты, потом снятие. В пределах одного типа порядок запросов не регламентируется.
▫️Test Cases стандарта
TODO
Гласит раздел этого стандарта и это странно, если его хотят добавить в Pectra
▫️Соображения безопасности
Необходимо обсуждение.
Указано в этом разделе.
▫️Вывод
Я смотрел интервью главного разработчика этого стандарта. В целом идея понятна и проста, унификация с заделом на будущее это очень хорошая тема. Но меня не много пугает, что до сих пор некоторые разделы стандарта являются белыми пятнами. Подозреваю, что это из-за связности с другими принимаемыми стандартами, что требует первоначального их внедрения и потом уже унификации. Посмотрим, в каком виде это уйдет в Pectra.
Более того, мне осталось не понятно, принимаемый стандарт EIP-6110 (по изменениям процесса депозита) будет сразу работать согласно EIP-7685 или нет. На мой взгляд, EIP-7685 не критичный, погоды сейчас он не сделает, вполне можно обойтись и без него на данном этапе. Время до внедрения Pectra есть, будем наблюдать.
#в_гостях_у_Pectra #павел_найданов