Книга «Создание смарт-контрактов Solidity для блокчейна Ethereum. Практическое руководство»

Parity иногда залипает. То не может в пул отправить транзакцию, то статус транзакций не может выдать.
Впрочем geth примерно также работал пару лет назад. Возможно сейчас лучше.

Я на parity с kotlin сделал платежный шлюз для трансфера токенов erc20.
Вроде работает предсказуемо, главное лишний раз не трогать движок и файлы блокчейна.

Можно, только средствами RPC (а значит, программно во время работы) вы их не увидите. По крайней мере в RPC я текста паники ни разу не видел. Я их использую просто как докуметацию в контракте.

Например, допустим у нас есть такой контракт.

contract PanicTest {
    function test() public {
        require(false, "Here be exception message");
    }
}

Думаете мы увидем в ответе текст ошибки? Как бы не так:

2019-10-16 11:37:10.603 +03:00 [VRB] RPC Request: {"id":1,"jsonrpc":"2.0","method":"personal_sendTransaction","params":[{"from":"0x8Ef4fb866d28D87B61229C0740996aD8160A1ecf","to":"0xe0ad0697f443de43b3d576a58f1e9f25f7e231d3","gas":"0x47b760","gasPrice":"0x0","value":"0x0","data":"0xf8a8fd6d"},"MyPassword"]}
2019-10-16 11:37:10.638 +03:00 [VRB] RPC Response: 0xfbaf7890f9c05ae0b51f3db06ee4e85b9c2895043a9384b307f527dfebce1ae5
2019-10-16 11:37:15.650 +03:00 [VRB] RPC Request: {"id":1,"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0xfbaf7890f9c05ae0b51f3db06ee4e85b9c2895043a9384b307f527dfebce1ae5"]}
2019-10-16 11:37:15.652 +03:00 [VRB] RPC Response: {
  "blockHash": "0x0739ce497cd5f04272541ccd63df1992fe8180327b6454ffa35b0aee5aa39ff1",
  "blockNumber": "0x2cdf",
  "contractAddress": null,
  "cumulativeGasUsed": "0x541f",
  "from": "0x8ef4fb866d28d87b61229c0740996ad8160a1ecf",
  "gasUsed": "0x541f",
  "logs": [],
  "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "root": null,
  "status": "0x0",
  "to": "0xe0ad0697f443de43b3d576a58f1e9f25f7e231d3",
  "transactionHash": "0xfbaf7890f9c05ae0b51f3db06ee4e85b9c2895043a9384b307f527dfebce1ae5",
  "transactionIndex": "0x0"
}

есть статус 0x0 — значит, транзакция не смогла смайниться и… И всё. Happy debugging, bitch (шутка).

Я это обходил через то, что я выставлял все проверки которые делаются в require как публичные bool-функции и проверял их после получения статуса 0:

protected static async Task<TransactionReceipt> WrapTransactionAsync(
    Func<Task<TransactionReceipt>> operation,
    params (Func<Task<bool>> isBusinessRuleFailed, Func<Exception> businessExceptionFunc)[] checks)
{
    try
    {
        return await operation();
    }
    catch (TransactionFailedException)
    {
        foreach (var (isBusinessRuleFailedAsync, businessExceptionFunc) in checks)
        {
            if (await isBusinessRuleFailedAsync())
            {
                throw businessExceptionFunc();
            }
        }
        throw;
    }
}

...

[ItemNotNull]

public Task<TransactionReceipt> ValidateTransactionAsync(string transactionHash, RequestStatusUpdate requestStatusUpdate)
{
    return WrapTransactionAsync(
        () => Web3.Client.GetTransactionReceiptAsync(transactionHash),
        (
            () => IsNewRequestAsync(requestStatusUpdate.ServiceNumber),
            () => new RequestNotFoundException(requestStatusUpdate.ServiceNumber)
        ),
        (
            async () => !await IsNewStatusAsync(requestStatusUpdate),
            () => new StatusAlreadyExistsException(requestStatusUpdate)
        ));
}

Надо ли говорить, что оно капец какое неудобное?.. Да и не работает в общем случае, просто чуть-чуть снижает боль для известных сценариев которые могут вызвать ошибку. В остальных случаях — "нишмагла, 0x0".

Хотя geth работает вполне стабильно в моих задачах, может и хорошо, что до parity руки не дошли.

Зависит от сложности ваших задач. У меня щас контракт перевалил за 2000 строчек и он за время работы сжирает под 2 триллиона газа.

Просто вот это — типичный код на солидити

А вот это — то, что мне приходится писать:

б0льшая часть претензий у меня к солидити, потому что solc это реально исчадие ада.

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

Compiler error: Stack too deep, try removing local variables.
1>     ...  uint128 dateRegNumPair = (uint128(date) << 64) | uint128(regNum); 
1>                                            ^--^

И или делай что хочешь. Разобъешь на маленькие функции? Отлично, теперь контракт не получится задеплоить потому что у него слишком большой размер (спасибо виталику). Включишь расширение чтобы нода позволяла обходить этот ЕИП и деплоить больше контракты? Еще что-нибудь отвалится. И так до бесконечности

К сожалению, этому API больше года, текущее 0.5.2. Код из книги вряд ли будет полезен и, скорее всего, не запустится.