2020-12-27 16:11

Trinity: dev mode

I would like to propose and work on a dev mode implementation for Trinity (as mentioned in "Do soon" list at https://github.com/ethereum/py-evm/issues/816). I suggest to follow ganache-cli behavior:

trinity --local

should start a local node, create accounts, reveal private keys for them, define gas-price and gas-limit (everything should be configurable).

Just want to ask if someone is already working on that and what are the main concerns here. Thanks.


  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答


  • weixin_39619433 weixin_39619433 4月前

    I'd be interested in a brief proposal of how you'd structure doing this. It's probably going to be harder to do before #1299 has been completed which could be a while.

    点赞 评论 复制链接分享
  • weixin_39611666 weixin_39611666 4月前

    If we're going to crib the argument name from another project, I'd look at geth or parity first. (--dev or --chain=dev respectively, I believe)

    点赞 评论 复制链接分享
  • weixin_39619433 weixin_39619433 4月前

    I think we'd do --dev which would go in the mutual exclusion group with --ropsten and be an alias for something like --network-id=1234 which is a special cased network ID that we use to configure the dev chain. In the EIP1085 world of #1299 this would just be another json document that defines the genesis state for a dev chain with potentially the special case of allowing some of the parameters to be configured by the user.

    点赞 评论 复制链接分享
  • weixin_39921224 weixin_39921224 4月前

    I thought it will be as simple as running node on some valid genesis block and disable sync to external nodes, adding few generated addresses and transactions on top of it... But from what you've mentioned above Trinity is not able to start without syncing from external nodes first (lol)... So any ETAs for finishing development on this feature? I read there are some fundamental issues with get_vm_... functions, were they resolved? How can I help with that?

    点赞 评论 复制链接分享
  • weixin_39619433 weixin_39619433 4月前

    the fundamental issues are likely to require a somewhat deep knowledge of the codebase so for now, while I have no problem with someone else fixing it, it will likely require one of the core contributors to fix.

    If you want to help move us forward a bit, I'd suggest looking at https://github.com/ethereum/py-evm/issues/835 and implementing one of the not-yet-implemented methods (FYI, that list may not be entirely up to date so cross check with the codebase to see if something has been implemented.)

    I'd suggest looking at how net_peercount is implemented for a general understanding of how these should be implemented:



    Looks like eth_syncing might be a good candidate.

    • new event pair for request/response to the syncer service.
    • new daemon_task in the syncer service that responds to these events.
    • full syncer here: https://github.com/ethereum/py-evm/blob/master/trinity/sync/full/service.py
    • light syncer here: https://github.com/ethereum/py-evm/blob/master/trinity/sync/light/service.py
    点赞 评论 复制链接分享
  • weixin_39619433 weixin_39619433 4月前

    Or this issue: https://github.com/ethereum/py-evm/issues/983

    But know upfront that it will likely be a pretty involved issue with a decent bit of just figure it out needed.

    点赞 评论 复制链接分享
  • weixin_39593744 weixin_39593744 4月前

    I just recently learned that geth has a --dev mode and so I wanted to revisit this issue to say that it may have become much simpler already to implement this. We've recently added a guide that explains how to setup a private developer testnet which makes me believe that the basic ingredients for a --dev mode should probably be here now.

    点赞 评论 复制链接分享