SB
why does we need to remove selfdestruct?
Size: a a a
2021 January 08
AV
Сильно усложняет БД и выполнение, тормозит разработку клиентов
SB
Сильно усложняет БД и выполнение, тормозит разработку клиентов
???
суисайд же изначально был задуман, что бы не захламлять блокчейн
суисайд же изначально был задуман, что бы не захламлять блокчейн
AV
???
суисайд же изначально был задуман, что бы не захламлять блокчейн
суисайд же изначально был задуман, что бы не захламлять блокчейн
Да-да, поэтому он полезен только для одной из моделей апгрейдов и для газтокенов.
Эта оптимизация нафиг не нужна - от неё место толком не экономится, зато надо хранить и проверять инкарнации.
Эта оптимизация нафиг не нужна - от неё место толком не экономится, зато надо хранить и проверять инкарнации.
AV
Вы в 1inch используете selfdestruct?
SB
Да-да, поэтому он полезен только для одной из моделей апгрейдов и для газтокенов.
Эта оптимизация нафиг не нужна - от неё место толком не экономится, зато надо хранить и проверять инкарнации.
Эта оптимизация нафиг не нужна - от неё место толком не экономится, зато надо хранить и проверять инкарнации.
Эта оптимизация нафиг не нужна
Это весьма спорное утверждение
Это весьма спорное утверждение
AV
Эта оптимизация нафиг не нужна
Это весьма спорное утверждение
Это весьма спорное утверждение
Ну мы в TurboGeth наелись ложкой selfdestruct, потому что фича непростая, а лежит под консенсусом
AV
Вообще это общий вопрос, что под консенсусом должна лежать простая логика, а все оптимизации должны быть изысками отдельных реализаций
AV
Почему идут разговоры о замене Merkle Patricia Tree на обычное двоичное дерево и т.п.
AB
Вы в 1inch используете selfdestruct?
Нам нечего удалять, ток в CHI gas token 😁
AV
Это хорошо, а газтокены должны гореть в аду )
SB
Вообще это общий вопрос, что под консенсусом должна лежать простая логика, а все оптимизации должны быть изысками отдельных реализаций
По моему это весьма простая логика
Если не хочешь использовать суисайд — ну не используй, в чем проблема-то? :)
Если не хочешь использовать суисайд — ну не используй, в чем проблема-то? :)
AV
По моему это весьма простая логика
Если не хочешь использовать суисайд — ну не используй, в чем проблема-то? :)
Если не хочешь использовать суисайд — ну не используй, в чем проблема-то? :)
Его всё равно нужно поддерживать иначе первый же вызов опкода приведёт к хардфорку
AV
Клиентам было бы намного лучше если бы могли его вырезать из протокола
SB
Клиентам было бы намного лучше если бы могли его вырезать из протокола
То есть вы говорите, что вы пишите клиент, и вам было бы намного удобнее, если бы в протоколе этой фичи вообще не было, так? :)
AV
То есть вы говорите, что вы пишите клиент, и вам было бы намного удобнее, если бы в протоколе этой фичи вообще не было, так? :)
Это даже не фича, а оптимизация
AV
Которая не оптимизирует, а калечит
SB
А на мой взгляд это отличная фича позволяющая уменьшать размер стейта хоть как-то
Я думаю, возможно его стоит как-то обновить или отрефакторить, но удалять такую важную вещь из протокола по моему мнению не стоит
Я думаю, возможно его стоит как-то обновить или отрефакторить, но удалять такую важную вещь из протокола по моему мнению не стоит