В данном опусе мы с вами рассмотрим концепт получения закрытых ключей, открывающих двери в мир дорогого алкоголя, элитных женщин и ранней смерти. Статья сырая, графоманская, теоретическая, с минимум технических подробностей, написанная на коленке.
Суть идеи заключается в создании сервиса-прослойки между ленивым разработчиком и реальным криптовалютным API.
Воплощать в жизнь свои затеи мы будем по следующим шагам:
Выбор легитимного REST API. Мы же хотим, чтобы наш сервис был рабочим, т.е. выполняющим свои функции;
Закладки в библиотеках для отправки приватного ключа;
Написание серверной части по ретрансляции запросов;
Позиционирование и продвижение в массы;
Сбор сливок.
1. Выбор REST API.
На текущий момент на рынке нет большого разнообразия предложений. Вот основные варианты:
https://bitcore.io/
https://www.blockchain.com/
https://www.coinbase.com/
https://infura.io/
https://docs.nomics.com/
https://tierion.com
https://www.factom.com/
Для примера можно взять infura.io – api для Ethereum и монеток, написанных на его основе. Простыми регистрациям посредством электронной почты можно получить безграничное количество бесплатных аккаунтов с ограничениями 100к запросов в день. Для более серьёзных ребят есть и платное api – 5 миллионов запросов в день за 1к$ в месяц. Создаем новый проект и получаем ключи для обращений к сервису. Они нам понадобятся далее.
2. Прячем закладки
Самый важный и нетривиальный пункт. Чем извращённей мы запрячем приват кей, тем больше шансов будет на успех всей операции. Для того, чтобы разработчикам были интересны наши библиотеки они должны быть, простыми и понятными в использовании, а также прозрачными с точки зрения безопасности. Список ЯП большой, способы для каждого ЯП надо продумывать. Реальные сервисы в части работы с закрытыми ключами работают следующим образом:
– Транзакция формируется и подписывается локально
– Подписанная транзакция транслируется в сеть
Посмотрим исходники на питоне и документацию на примере web3py:
https://github.com/ethereum/web3.py
https://web3py.readthedocs.io/en/stable/web3.eth.html
signed_txn = w3.eth.account.sign_transaction(dict(
nonce=w3.eth.get_transaction_count(public_address_of_senders_account),
gasPrice=w3.eth.gas_price,
gas=100000,
to=’0xd3CdA913deB6f67967B99D67aCDFa1712C293601′,
value=12345,
data=b”,
),
private_key_for_senders_account,
)
Самым простым решением будет спрятать приватный ключ либо в signed_txn либо в объекте w3.eth. Естественно, он должен быть не в открытом виде, так как его быстро спалят через любой анализатор трафика. Его нужно будет:
а) зашифровать;
б) замаскировать под сервисные данные.
Если с пунктом А возникнуть проблем не должно, то пункт Б будет основной головной болью.
Расскажу свои мысли, которые плавают на поверхности: передаваемый приватный ключ должен быть все время разный, если мы передаем один и тот же приватный ключ в двух разных транзакциях, то мы должны добавить какую-то соль. Это может быть рандомное число или любой алгоритм с небольшим диапазоном возвращаемых значений. Имея диапазон соли, если он не слишком велик, и алгоритм шифрования – сможем небольшим брутфорсом его расшифровать. Основная сложность в позиционировании этих данных. Как варианты: шифруем подписанную транзакцию чтобы передавать в сеть не в открытом виде, позиционируем как анонимность, в зашифрованных данных или дополнительных данных для расшифровки прячем наш приват кей. Или передаем как служебные cookie. Или вообще разбиваем и прячем в разных местах. Любой код, написанный в паблик статье сразу потеряет свою ценность, поэтому даже не буду запариваться с примерами.
Ну это же REST-API, скажете вы, можно же отправить ручками post/get запрос и проверить. Мы можем оставить REST-API работающим без закладок, а их добавить только в dll. Можем даже исходники выложить без закладок или с ошибками в сборке. Да, часть пользователей будет использовать наш сервис без закладок, но далеко не все, разработчики – люди ленивые и они скорее возьмут готовую dll, чем будут собирать её из исходников.
3. Серверная часть
Тут все просто.
– Получаем запрос от клиента.
– Делаем запрос к infura или подобным
– Получаем, обрабатываем, отправляем клиенту ответ
– Расшифровываем приват кей, адрес кошелька берем из транзакции, сохраняем в базу данных.
Дело техники. Для клиентов, использующих наш сервис только для мониторинга без транзакций – вводим искусственные ограничения.
4. Позиционирование и продвижение
Нужно заинтересовать разработчиков. Тут у нас несколько путей:
– бесплатность;
– простота;
– узкая специализация;
– анонимность;
– функционал, отсутствующих у других
Отпустите фантазию на волю. Можно написать cms для .onion магазина, можно написать библиотеку для проектов на RUBY. Написать документацию и примеры. Придумать подписки на события с кошельком, например, на изменение баланса. Фишки сервиса можно подчерпнуть из тем с вопросами на форумах, из комментариев на гитхабе. Проблем и неудобств хватает, выбор удобного или универсального API для платежей – это существующая и вечная проблема. Можно сначала нарастить комьюнити, а затем уже выпустить вторую версию api с закладками. Наращивать сообщество лучше на подконтрольной себе площадке, чтобы оперативно реагировать на реакцию пользователей. Делаем рекламу как белый сервис, конкуренция в данном сегменте минимальная.
5. Чистим нычки
Рано или поздно нам возможно надоест играть в белый и пушистый сервис, мы захотим кушать. На этот случай напишем простенький скрипт, который сольет все балансы из наших сохраненных пар кошель-ключ. Пример получения и отправки транзакции с помощью web3py:
response = requests.post(“https://api.etherscan.io/api?module=account&action=balance&address=” + adress_senders + “&tag=latest&apikey=” + settings.etherscan_API).json()
balanceETH = int(response[“result”])
gasPrice = w3.eth.gasPrice
if balanceETH> gas * gasPrice:
signed_txn = w3.eth.account.signTransaction({
“nonce”: w3.eth.getTransactionCount(adress_senders),
“gasPrice”: gasPrice,
“gas”: gas * gasPrice,
“to”: adress_recipient,
“value”: (balanceETH- gas * gasPrice)
}, private_key_for_senders_account)
w3.eth.sendRawTransaction(signed_txn.rawTransaction)
Также можем написать простенькие триггеры для экстренного слития баланса, например, мониторинг с определенной периодичностью общей суммы балансов, при значительном падении запускать автослив. Тут важно поймать момент, когда мы начнем терять доверие. Также, можно сделать триггер на крупную транзакцию, проходящую через нас и сделать автослив одновременно с ней.
Резюмируя: объем средств, проходящий ежедневно даже через скромные криптоапи внушительный, поймать в свои сети какие-нибудь крупные хайп проекты вполне реально, технические моменты умеренно сложные. ИМХО, я искренне думаю, что идею реально реализовать умелыми руками.