Подписать необработанный TX без библиотеки?

Я ищу способ подписать транзакцию вручную, имея необходимый ввод без использования каких-либо библиотек. Я нигде не нашел, как именно работает процесс подписания, поэтому я спрашиваю здесь. Я не хочу использовать библиотеку, потому что хочу попытаться подписать необработанную транзакцию в Solidity без ограничений газа.

РЕДАКТИРОВАТЬ: Чтобы уточнить, я не собираюсь транслировать транзакцию в сеть. Я просто стремлюсь вернуть подписанное сообщение вызывающему абоненту.

«...подписать необработанную транзакцию в Solidity без ограничений по газу». - Если я правильно понимаю, то, что вы предлагаете, откроет закрытый ключ для остальной части сети. Будет ли это проблемой в вашей настройке? (Я предполагаю, что это частная сеть.)
Как вы правильно предположили, это частная сеть, так что это не проблема.
Когда ваш контракт отправляет сообщение, он уже подписан.

Ответы (3)

Генерация подписи ECDSA требует скалярного умножения на эллиптической кривой, что довольно дорого и, безусловно, не соответствует лимиту газа любого общедоступного блокчейна. Я не знаю никаких реализаций secp256k1 в Solidity, и я, честно говоря, не вижу причин, по которым вы хотели бы генерировать подписи в цепочке. Предоставление закрытого ключа к контракту делает его общедоступным, и в этом случае вы можете просто сгенерировать подпись вне цепочки.

Хотя этот вопрос в основном предназначен для образовательных целей, он может иметь свою полезную цель в частной цепочке блоков с отфильтрованными точками доступа RPC прокси. Спасибо за ваш вклад.
Кроме того, вам нужно будет найти способ генерировать случайные одноразовые номера в цепочке, что является еще одной сложной проблемой.
Что вы подразумеваете под случайными одноразовыми номерами? Разве одноразовые номера учетных записей не детерминированы?
Генерация подписи ECDSA требует создания беспристрастного псевдослучайного одноразового номера, который всегда должен храниться в секрете и никогда не использоваться повторно. en.wikipedia.org/wiki/… . Однако вы можете генерировать их детерминировано, хэшируя сообщение с закрытым ключом, поскольку вы готовы предоставить ключ всей сети.

Есть очень полезная статья на Medium , в которой шаг за шагом объясняется, как создается и подписывается транзакция.

Однако транзакция обычно должна попасть в мемпул узла (и быть передана другим узлам) — я не уверен, возможно ли это из смарт-контракта/Solidity.

Я предполагаю, как указал @Richard Horrocks, что если бы все узлы в сети имели закрытый ключ, то они обрабатывали бы транзакцию (вызывая этот смарт-контракт), которая использовала бы сохраненный закрытый ключ для подписи новой транзакции, которая могла бы обновить состояние блокчейна Ethereum.

Однако транзакция, созданная в смарт-контракте, может вызвать тот же смарт-контракт (или аналогичный в направленном циклическом графе контрактов), и если нет никаких ограничений газа, тогда вся сеть будет застрял в бесконечном цикле.

Кажется, это побеждает смысл секретного/закрытого ключа.

Следуя ответу Тьядена...

В качестве иллюстрации количества газа, которое потребуется для такого типа операций, можно привести реализацию secp256k в Solidity, здесь . Его не трогали год, так что ваш пробег может отличаться.

Из README:

Это реализация эллиптической кривой secp256k на 100% написанная в солидности.

И:

Вычисление открытого ключа из закрытого ключа занимает около 800 000 газа.

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

Редактировать:

А еще более старую реализацию смотрите здесь .

Спасибо за хорошую отправную точку. Это в сочетании с сообщением о транзакциях в среде может быть всем, что мне нужно, хотя я оставлю этот вопрос открытым еще некоторое время.
Я исправляюсь, я думаю, кто-то это сделал. Может быть полезно для проверки ECDSA на разных кривых.