Транзакции не добываются, если я отправляю слишком много

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

Например: если я отправляю одну транзакцию каждые 6 секунд, то ни одна транзакция не будет добыта. Если я отправляю одну транзакцию каждые 30 секунд, то все работает нормально.

Я отправляю транзакцию с nodejs следующим образом:

instance.myFunction(data, {from: account.address, gas: 4000000}, function(error, result) {
// do something
});

Транзакции просто накапливаются и не добываются майнером.

Вот, например, две транзакции:

> eth.getTransaction( '0x1e06fec8994ee38a32b2438d51b57c9d4bc95239c45322d58a4a9f0c8a03be4a')
{
  blockHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
  blockNumber: null,
  from: "0x7ee9e416fdb371a9190dfa8fdf7361e66ada7e12",
  gas: 4000000,
  gasPrice: 18000000000,
  hash: "0x1e06fec8994ee38a32b2438d51b57c9d4bc95239c45322d58a4a9f0c8a03be4a",
  input: "0x4ee27fa900000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000006313530313331393039383234343b343000000000000000000000000000000000313530313331393039393234383b323400000000000000000000000000000000313530313331393130303235323b353500000000000000000000000000000000313530313331393130313235363b373700000000000000000000000000000000313530313331393130323236313b393100000000000000000000000000000000313530313331393130333236353b313800000000000000000000000000000000",
  nonce: 107,
  r: "0xe761ccc9db6d387eadba7bcb93dac6c582f8baf052da76eaff828e5b91c1722d",
  s: "0x571f99554f299d551bb05bb6145210a6480c015b42604f9bd885de6eea94dbcb",
  to: "0x8e195493424d416300f8b61b01145956345cd914",
  transactionIndex: 0,
  v: "0x42",
  value: 0
}
> eth.getTransaction('0x02e09d88360c27f6da92075a8ab1f8e2bb23bca149004a3d134048492348677d')
{
  blockHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
  blockNumber: null,
  from: "0x7ee9e416fdb371a9190dfa8fdf7361e66ada7e12",
  gas: 4000000,
  gasPrice: 18000000000,
  hash: "0x02e09d88360c27f6da92075a8ab1f8e2bb23bca149004a3d134048492348677d",
  input: "0x4ee27fa900000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000006313530313331393130343331353b343000000000000000000000000000000000313530313331393130353331373b353700000000000000000000000000000000313530313331393130363332313b383500000000000000000000000000000000313530313331393130373332363b313500000000000000000000000000000000313530313331393130383332393b363000000000000000000000000000000000313530313331393130393333323b323000000000000000000000000000000000",
  nonce: 108,
  r: "0x183a1fc9c149ece66ed8e782758f7980d3b01c88595662e769171e155749dc4a",
  s: "0xfd9abed2168cae1e33c2bd4441015178e54aa3fb1c742f4f613d9d3c140ef4",
  to: "0x8e195493424d416300f8b61b01145956345cd914",
  transactionIndex: 0,
  v: "0x41",
  value: 0
}

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

Я использую веб3 версии 0.20.0.

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

update : я пытался переопределить одноразовый номер вручную, но это не помогло. Все транзакции просто ставятся в очередь в пуле транзакций:

> txpool
{
  content: {
    pending: {},
    queued: {
      0x7ee9e416fdb371a9190dfa8fdf7361e66ada7e12: {
        110: {...},
        111: {...},
        112: {...},
        113: {...},
        114: {...},
        115: {...},
        116: {...},
        117: {...},
        118: {...},
        119: {...},
        120: {...},
        121: {...},
        122: {...},
        123: {...},
        124: {...},
        125: {...},
        126: {...},
        127: {...},
        128: {...},
        129: {...},
        130: {...},
        131: {...},
        132: {...},
        133: {...},
        134: {...},
        135: {...}
      }
    }
  },
  inspect: {
    pending: {},
    queued: {
      0x7ee9e416fdb371a9190dfa8fdf7361e66ada7e12: {
        110: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        111: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        112: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        113: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        114: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        115: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        116: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        117: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        118: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        119: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        120: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        121: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        122: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        123: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        124: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        125: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        126: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        127: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        128: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        129: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        130: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        131: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        132: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        133: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        134: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        135: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas"
      }
    }
  },
  status: {
    pending: 0,
    queued: 26
  },
  getContent: function(callback),
  getInspect: function(callback),
  getStatus: function(callback)
}

это функция в моем контракте, которая вызывается:

/**
 * save sensor data
 * @param   data    sensor data timestamp;value
 * @return  bool
 */ 
function saveSensorData(bytes32[] data) returns (bool success)
{
    if(sensors[msg.sender].exists)
    {
        for(uint i = 0; i < data.length; i++) {
            sensors[msg.sender].sensorData.push(data[i]);
        }

        return true;
    }

    return false;
}
Одной из проблем является значение nonce, каждая транзакция должна иметь последовательный возрастающий номер. Если вы отправляете транзакции слишком быстро, клиент geth может не поддерживать свое внутреннее состояние в актуальном состоянии. В этом случае вы должны получить следующий одноразовый номер с помощью getTransactionCount в начале, а затем переопределить значение по умолчанию для последующих транзакций, каждый раз увеличивая его на единицу.
Я проверю это и посмотрю, не проблема ли это со значением nonce
Я видел похожие симптомы даже там, где nonce определенно отличается. См. также этот (в настоящее время без ответа) вопрос, который, похоже, относится к похожей теме: ethereum.stackexchange.com/questions/23073/…
Я пытался установить одноразовый номер вручную, но это не помогло, я почти уверен, что одноразовый номер правильный, все транзакции поставлены в очередь в пуле транзакций (см. мое обновление)
Я заметил, что ваша транзакция является вызовом контракта, что делает ваш контракт?
ничего особенного, он просто сохраняет массив данных - я разместил функцию, которая вызывается
Это действительно странная функция, потому что она объявлена ​​как константа и не должна изменять состояние транзакции, но она это делает. Вы уверены, что ваша транзакция выполняется правильно? Какую версию компилятора Solidity вы используете?
ups, извините ^^, это неправильный вариант, я удалил константный модификатор (это была ошибка, которую я сделал несколько дней назад). Да, я на 100% уверен, что контракт работает должным образом. Я использую Solidity v0.4.11 и Truffle v3.4.5 для компиляции
Когда позволит время, я сделаю тест с контрактом и соответствующим образом обновлю ответ.

Ответы (2)

Похоже на ошибку, которую только что исправили: https://github.com/ethereum/go-ethereum/issues/14893 .

Я сделал это с частной тестовой сетью без проблем.

arr=[];
start=eth.getTransactionCount(eth.accounts[0]);
for (i = 0; i<= 200; i++) {
    arr.push(eth.sendTransaction({
        from: eth.accounts[0],
        to: eth.accounts[1],
        nonce: start+i,
        value: web3.toWei(1 , 'szabo')}));
}
miner.start(1);
admin.sleepBlocks(10);
miner.stop();

Найдена 201 транзакция в трех блоках

> eth.getBlock(15).transactions.length
0
> eth.getBlock(16).transactions.length
98
> eth.getBlock(17).transactions.length
98
> eth.getBlock(18).transactions.length
5
> eth.getBlock(19).transactions.length
0

Образец блока

> eth.getBlock(16)
{
  difficulty: 131072,
  extraData: "0xd783010605846765746887676f312e382e33856c696e7578",
  gasLimit: 2133025,
  gasUsed: 2058000,
  hash: "0x02efd3e3ff324f38a1b6b2900e58a39ae3cca30b41fc18d45cf4b6d1a2dd73ec",
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  miner: "0x7ab9a957982ba2fd5665fccfc3c603b87931b1c9",
  mixHash: "0xf4a979afdc276b6bfc7d7dd1a6ba33d509d04bbfb5d7d65514bd5d4223e829ab",
  nonce: "0x292177014c2c726b",
  number: 16,
  parentHash: "0x1dcb415a3cedbbccaf21cefecadf02df46fbbceffad19bf62c9bcd5f2bf7466b",
  receiptsRoot: "0xe783695d43236e24a353adc1d48868ba90ae4e3f3eef98071c2c81016a9d8ac2",
  sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  size: 11215,
  stateRoot: "0x0c911d8345371e7be2236e548c8ad331449fc1dff93a943a35467428a608ed7a",
  timestamp: 1501385226,
  totalDifficulty: 2101184,
  transactions: ["0x6751df4f6bf8ffc580a87cd9ed3a88795133c0a5408f889999b5a2bda25b2469", 

Пример транзакции

> eth.getTransaction(eth.getBlock(16).transactions[0])
{
  blockHash: "0x02efd3e3ff324f38a1b6b2900e58a39ae3cca30b41fc18d45cf4b6d1a2dd73ec",
  blockNumber: 16,
  from: "0x7ab9a957982ba2fd5665fccfc3c603b87931b1c9",
  gas: 90000,
  gasPrice: 18000000000,
  hash: "0x6751df4f6bf8ffc580a87cd9ed3a88795133c0a5408f889999b5a2bda25b2469",
  input: "0x",
  nonce: 122,
  r: "0xece247cd6ad1d19c1fbd997a860c111aa17dcfdfc11535ad9bad8d6f41e2e18c",
  s: "0x4a5dee5a9e4a2a099d070092024ed502a4c8d324badd8fa370d028c2a2c0f61c",
  to: "0x055a11dd8f2c2a2994d380da499c2f4920d969c6",
  transactionIndex: 0,
  v: "0x41",
  value: 1000000000000
}

Образец квитанции

> eth.getTransactionReceipt(eth.getBlock(16).transactions[0])
{
  blockHash: "0x02efd3e3ff324f38a1b6b2900e58a39ae3cca30b41fc18d45cf4b6d1a2dd73ec",
  blockNumber: 16,
  contractAddress: null,
  cumulativeGasUsed: 21000,
  from: "0x7ab9a957982ba2fd5665fccfc3c603b87931b1c9",
  gasUsed: 21000,
  logs: [],
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  root: "0x7733965c0b1b35e98fbb60721c56f69225b8328f77e2e043c03ce038c0f1e4c0",
  to: "0x055a11dd8f2c2a2994d380da499c2f4920d969c6",
  transactionHash: "0x6751df4f6bf8ffc580a87cd9ed3a88795133c0a5408f889999b5a2bda25b2469",
  transactionIndex: 0
}

Используется частный тестнет genesis.json

$ cat genesis.json 
{
    "config": {
        "chainId": 15,
        "homesteadBlock": 0,
        "eip155Block": 0,
        "eip158Block": 0
    },
    "difficulty": "0x400",
    "gasLimit": "2100000",
    "alloc": {
        "7ab9a957982ba2fd5665fccfc3c603b87931b1c9": { "balance": "200000" },
        "055a11dd8f2c2a2994d380da499c2f4920d969c6": { "balance": "400000" }
    }
}
спасибо, я пробовал это, но это не помогло - я почти уверен, что одноразовый номер правильный
Я вижу те же симптомы даже с этим скриптом (и могу подтвердить, что в моих предыдущих тестах все одноразовые номера были уникальными). Бесит то, что в одном или двух случаях скрипт извлек все txns из 2 или 3 блоков, но в большинстве случаев он просто теряет txns, которые не попали в первый блок. Какую среду вы используете?
Подробности в ответе, но это частная тестовая сеть, работающая на одном узле. У вас есть более одного экземпляра geth в качестве партнера? У меня были аналогичные проблемы при отправке транзакции с двух узлов одновременно с использованием одной и той же учетной записи.
Привет, @Ismael, я имел в виду, на какой ОС ты работаешь? Если я использую эквивалентный вам genesis.json (то есть без блока распределения, поскольку у меня нет этих учетных записей на моем узле), то у меня будут те же симптомы отсутствия txns после 1 блока. Я использую один узел geth, Ubuntu 16.04 и geth 1.6.7-stable-ab5646c5.
Извините, это i7-4770k 3.5Ghz, 32Gb ram, 500Gb ssd, Ubuntu 16.04.02, Geth 1.6.7-stable из официального ppa.
Я еще немного поиграл и смог увидеть ситуацию, когда иногда это работает, а иногда нет. Моего гет-фу недостаточно, чтобы разобраться самому, поэтому я поднял вопрос: github.com/ethereum/go-ethereum/issues/14893
Извините, но я не могу воспроизвести вашу ошибку. Пробовали ли вы перезапустить гет-узел, чтобы убедиться, что в начале нет ожидающих транзакций? Здесь ethereum.stackexchange.com/questions/3831/… — более подробный ответ о пуле транзакций. Возможно, у geth не хватает памяти.
Привет @Ismael. Спасибо за ссылку и предложение, но geth, похоже, отлично с этим справляется. Я немного покопался и обновил проблему github, добавив больше информации о том, что я нашел. Кажется, это связано с порядком запуска событий.