вряд ли. Валидатор постоянно подписывает блоки, а фишка аппартного кошелька - что подпись происходит внутри него. Т.е. кошелек должен довольно шустро подписывать блоки через USB. Это может быстро пожирать его ресурс, да и скорость думаю там очень невысокая - все таки процессор у него в кишках не i7. Так что сомневаюсь, что этот сетап нормально работает

в случае Delegated ProofOsStake лучше чтобы валидатор работал с адреса, на котором нет много крипты, а а него просто голосует другой адрес, который уже в свою очередь защищен аппаратным кошельком

В етх2 валидатора два ключа. Один подписи блоков и управления состоянием. Этот должен быть постоянно доступен ноде. Но им нельзя сделать перевод баланса. Это типа горячий кошелёк. Второй наоборот, может только делать перевод. Вот его то и хотелось иметь аппаратным.

а, я не увидел что это для ETH 2.0 - фиг знает как там. В любом случае там где аппаратный кошель, а на ноде файлик или опция с приватником - придется довольно серьезно шаманить, т.к. аппаратный кошелек наружу приватный ключ никогда не отдает

есть mpc протоколы с настраиваемыми порогами подписи, построенные для использования в системах с secp256k1 и ed29519. Их часто используют для обеспечения безопасности бирж и крупных майнеров. На основе этих протоколов созданны решения vHSM, сертефицированные по fips 140-2 lv2.

Суть этих решений в разделении идентичности(ключа) на партии, расположенные в несвязанных устройствах, заточенных под специфичные режимы работы. Это позволяет использовать различное оборудование для критичных к задержкам операциям, но не критичным к движению капитала и критичных к движению капитала но не критичным к задержкам на разные устройства. Но как можно догадатся эти решения сильно за пределами возможностей обычных кошельков.

Есть еще  рекурсивные ZKP, но они пока в альфе и там еще больше тонкостей.

Это все компаративные решения. Я в сценарии одинокая нода валидатора етх2 тихонько шуршит на вдс. Как обезопасить ключи?

Превосходный summary по деталям запуска стейкинга ETH2

https://www.trustnodes.com/2020/11/12/just-10-deposit-to-stake-on-ethereum-2-0

Привет. Скажите а может ли контракт зафэйлить транзакцию если на него слать эфир?

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

Если в контракте не предусмотрена функция payable

Токены по умолчанию нельзя, только если создатель не предусмотрел функцию приема токенов. Как правило по умолчанию токены пропадат, в редких случаях идет отлуп от контракта

Спс большое)

Всем привет

Подскажите проверенный рандомайзер

У цеппелина нет

Chainlink VRF - https://blog.chain.link/verifiable-random-functions-vrf-random-number-generation-rng-feature/
По-крайней мере PoolTogether его используют - https://chainlinkecosystem.com/ecosystem/pooltogether/

Благодарю

The bulk of Ethereum’s DeFi ecosystem went dark yesterday after a latent bug in the Ethereum code split the network’s transaction history in two. Ethereum node operators ignored the update, which ironically was meant to prevent the very split that occurred.

The case is perhaps Ethereum’s greatest challenge since the 2016 DAO fork, and it raises questions about Ethereum’s oft-touted decentralization and the effectiveness of its developer coordination going into Ethereum 2.0.

$ETH

www.coindesk.com/ethereums-hard-fork-disruption

Подскажите. Если есть задача с одного адреса раскидать эфир на разные адреса, тут же не поможет свой смартконтракт в плане экономии газа?
Как я понимаю, самое дешевое это просто на каждый перевод делать отдельную транзу, и запускать их последовательно.

Или я ошибаюсь и контракт может сделать тут экономию?

З.Ы. Уточнения:
1) Идет речь о рассылке эфира
2) Мы не знаем заранее адреса получателей. Т.е. в контракте мы не можем их захардкодить при создании.

Если в смарт-контракте заранее предусмотреть функцию массовой рассылки, коорая принимает два массива - адресов и количества и рассылает по всем, то можно сэкономить до 30-40% газа по сравнению с просто поадресной рассылкой