Как обрабатывать эфирные депозиты, как это делают биржи?

Вы задали ряд вопросов в дополнение к вашему основному вопросу о том, как обращаться с эфирными депозитами.

Основная проблема, с которой вы пытаетесь справиться, — это проблема двойной траты . Если кто-то вносит депозит на вашу биржу Dapp, как вы гарантируете, что средства не будут потрачены дважды, и как вы поступите со средствами, которые были депонированы, а затем фактически не израсходованы из-за форка?

Ответ несколько на ваше усмотрение как разработчика DAPP Exchange — вам решать. Так почему бы не выбрать 24 блока или, как это делает одна биржа, 360 блоков? В зависимости от того, что дает вам уверенность, в которой вы нуждаетесь.

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

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

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

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

Каковы последние рекомендации по количеству подтверждений транзакций в выпуске Homestead?

Согласно API-интерфейсам web3, 12 блоков — это хорошо, чтобы убедиться, что нет форка. Что касается подтверждений транзакций... Я бы сказал, что 5 - это по-прежнему сумма де-факто, которую вы хотите там. Это, очевидно, изменится с Serenity, и я не был бы уверен, как ответить на это, учитывая огромные изменения, которые Каспер принесет с собой. Следите за блогом Виталика, чтобы помнить об этом во время разработки.

Существуют ли какие-либо библиотеки или службы, предоставляющие примеры реализации?

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

Какова грубая реализация псевдокода, чтобы справиться с этим самостоятельно?

что-то вроде этого

js:

var i = myEthereumEvents
myEthereumEvents.watchAllEvents() {
    if (eventHit)
         var boolean = contract.promisifiedCheckBalanceOfPeer()
         if (boolean)
              contract.exchangeTokenValue()
}

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

Дайте мне знать, если это ответит на ваш вопрос.