Телеграмм чат группы eth

для разблокирования, что бы потом мог применить метод контракта

14:43пожаловаться #1

Всем ещё раз привет
Если кто-то подскажет - буду очень признателен
Unlock:

const wss = 'wss://speedy-nodes-nyc.moralis.io/.../polygon/mainnet/ws';
web3 = new Web3(new Web3.providers.WebsocketProvider(wss));
web3.eth.personal.unlockAccount("0x...", "pass...",600)

Получаю ответ:
Error: Returned error: the method personal_unlockAccount does not exist/is not available

16:06пожаловаться #2

Можете пояснить - как правильно в web3 делать unlock?

16:06пожаловаться #3

Спасибо!

16:06пожаловаться #4

Qox in Ethereum Russia

personal вроде geth метод

16:37пожаловаться #5

Qox in Ethereum Russia

и юзается на своей ноде, а не на делегированном эндпоинте

16:38пожаловаться #6

Да, я тоже так понял

16:48пожаловаться #7

Спасибо

16:48пожаловаться #8

думаю правильное решение для апгрейдов пулов - это таймлоки
например, upgrader прокси - адрес таймлок контроллера, у которого единственный proposer - адрес governance контракта
тогда все апгрейды пройдут через голосование и временную блокировку

17:16пожаловаться #9

читал что идею придумал Сатоши Накамото)
nSequences -> HTLC -> современный timelock controller)

17:53пожаловаться #10

Зачем таймлок, если голосование и так во времени процесс растягивает. Ты ж не можешь мгновенно проголосовать за решение

18:00пожаловаться #11

В смысле проголосовать то сможешь, но решение не будет принято до окончания срока голосования

18:00пожаловаться #12

таймлок чтобы после голосования дать время людям выйти из протокола не спеша

18:01пожаловаться #13

они это могут сделать пока голосование идет

18:02пожаловаться #14

если голосование идет, но результат уже известен, то да

18:04пожаловаться #15

если решение жизненноважное, и с непредсказуемым результатом, то таймлоковость принятия решения можно прописать в самом пропозале. Сам по себе таймлок неудобная штука, как по мне

18:05пожаловаться #16

поэтому по дефолту его втыкать на все решения - лично мне не очень нравится

18:06пожаловаться #17

согласен
возможно timelocked governance -это слишком во многих случаях)
но если владелец протокола админ-частник, то таймлоковость нужна

18:13пожаловаться #18