by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 20:27
    cemozerr edited #2857
  • 20:27
    cemozerr edited #2857
  • 20:27
    cemozerr synchronize #2857
  • 20:27
    cemozerr opened #2857
  • 20:19
    cemozerr edited #2794
  • 20:19
    cemozerr edited #2794
  • 20:19
    cemozerr edited #2794
  • 20:17

    benjamincburns on gh-pages

    Automated REST API documentatio… (compare)

  • 20:06

    cemozerr on master

    Add Spadina genesis state (#285… (compare)

  • 20:06
    cemozerr closed #2856
  • 19:55

    benjamincburns on gh-pages

    Automated REST API documentatio… (compare)

  • 19:53
    cemozerr synchronize #2856
  • 19:46
    cemozerr edited #2856
  • 19:46
    cemozerr edited #2856
  • 19:46
    cemozerr opened #2856
  • 19:42

    cemozerr on master

    Fix GenesisGenerator top-up dep… (compare)

  • 19:42
    cemozerr closed #2855
  • 19:31
    cemozerr edited #2855
  • 19:30
    cemozerr edited #2855
  • 19:30
    cemozerr opened #2855
Sylvain Laurent
@Magicking
Many thanks
Raw Pong Ghmoa
@q9f
hi, do you have a tracker for v0.12 ?
asking for a testnet goerli/witti#17
Adrian Sutton
@ajsutton
@q9f We didn't but I've just created: PegaSysEng/teku#2038 All the work is planned for our current sprint so should be done in the next 2 weeks. The two big items are the BLS and Gossipsub changes which already have PRs open so aren't too far off. It sounds like we'll get a 0.12.1 with the genesis time tweaks you want soon so I'm keen to jump straight to that.
Adrian Sutton
@ajsutton
Teku v0.11.3 is out: https://github.com/PegaSysEng/teku/releases/tag/0.11.3 I still recommend people track master but if you haven't updated in a little while, now's a good time. :)
Raw Pong Ghmoa
@q9f
:+1:
Coin Sights
@YangLingchi_twitter
ubuntu@ubuntu:~/tmp/teku$ ./gradlew distTar installDist
Configuration on demand is an incubating feature.

FAILURE: Build failed with an exception.

* Where:
Build file '/home/ubuntu/tmp/teku/build.gradle' line: 588

* What went wrong:
A problem occurred evaluating root project 'teku'.
> Cannot invoke method head() on null object

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.4.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 4s
Got this error. Anyone help?
Ben Edgington
@benjaminion
Hi @YangLingchi_twitter - what's your java --version?
Ben Edgington
@benjaminion
This seems to be related to the Grgit Gradle plugin (PegaSysEng/teku#1613) - we're investigating and will let you know what we find.
Adrian Sutton
@ajsutton
@YangLingchi_twitter It looks like you've downloaded the zip file from GitHub rather than using a git checkout so we couldn't calculate the git hash to include in Teku's version string. We'll look into fixing that but in the mean time if you checkout with git clone https://github.com/PegaSysEng/teku.git the build should work. Or you can use the pre-built binaries from https://bintray.com/consensys/pegasys-repo/teku
Adrian Sutton
@ajsutton
I've logged PegaSysEng/teku#2055 to track this.
Piotr Blasiak
@piotrblasiak
Hi. Does anyone know if the BLS12-381 module is available by maven anywhere? I know it was before under another name but doesn't seem to be anymore and I can't include teku using jitpack either. I think publishing that as a module would be very useful to a lot of people as it is becoming a standard and there is no simple solution to it for java out there.
Adrian Sutton
@ajsutton
@piotrblasiak The jars for all of Tekus modules get published to https://bintray.com/consensys/pegasys-repo/teku We can’t currently make any guarantees about preserving api compatibility because things keep changing too fast but it should be there if it’s useful.
Piotr Blasiak
@piotrblasiak
@ajsutton oh, perfect thank you
Piotr Blasiak
@piotrblasiak
Another question - I am still new to BLS - the tests specify different entropies in the different tests. What's the correct way to generate a valid random BLS12381 keypair?
Ben Edgington
@benjaminion
Here's an example in Java: https://github.com/PegaSysEng/teku/blob/81deceb0070d240768fe3a43fa833fbb3604e9e2/teku/src/main/java/tech/pegasys/teku/cli/deposit/DepositGenerateCommand.java#L142 - be sure that the RNG is strong. This is part of our toolchain teku validator generate that creates and saves keypairs and registers the deposit on the Eth1 chain. Currently you can't use this only to generate keypairs, but we plan to allow that at some point (PegaSysEng/teku#1889).
BTW, note that the BLS implementation is being updated currently. We have it on a branch right now, but not yet in master: PegaSysEng/teku#1895
Piotr Blasiak
@piotrblasiak
great, thanks!
herbic1d3
@herbic1d3
Hello, everyone!
I have run a separate beacon and validator on different instances. How do I specify the validator parameter to connect the beacon node provider?
Adrian Sutton
@ajsutton
Hi @herbic1d3 Teku runs the validator client in the same process as the beacon node. So you just need to start teku and provide the validator keys via the --validators-key-files and --validators-key-password-files options. https://docs.teku.pegasys.tech/en/latest/HowTo/Get-Started/Connect-To-Testnet/ has instructions for the whole process of registering a validator and using Teku to validate.
herbic1d3
@herbic1d3
Hi, @ajsutton A beacon node run on instance with ip 10.0.0.2, validator run on instance with ip 10.0.0.3. With which parameter do I start the validator for connection?
Adrian Sutton
@ajsutton
@herbic1d3 There isn't a separate validator for teku. So you only need one of those two.
Raw Pong Ghmoa
@q9f
would you be interested to run a genesis validator on altona in the coming weeks? who'd be the best point of contact for teku?
Adrian Sutton
@ajsutton
@q9f yep that would be good. Probably the best contacts are me and @benjaminion - he’s more in your timezone and I can get things set up on our infrastructure with monitoring etc.
Raw Pong Ghmoa
@q9f
ok
will reach out once we are getting there :)
Raw Pong Ghmoa
@q9f
14:54:21.914 INFO  - Initializing storage                                                                                                                                                                                                     │···············
Is there anything I can do to speed this up? It's taking more than 15 minutes already
Adrian Sutton
@ajsutton
@q9f It is slow but making sure it has plenty of RAM is key at the moment. Teku can drop non-finalised states from memory but not non-finalised blocks so memory requirements are pretty high now. A t3.medium with 4Gb RAM is pretty much unable to cope - t3.large with 8Gb probably would work but I've skipped to the xlarge with 16Gb for the Teku nodes I'm running on Witti and they're now keeping up. On those I've set -Xmx8g. I'd suggest -Xmx4g on a box with 8Gb of RAM.
Pawan Dhananjay
@pawanjay176
hey @ajsutton do you guys have a teku node on the onyx testnet I can sync from? was trying to debug some yamux issues with lighthouse
Ben Edgington
@benjaminion
@pawanjay176 we're currently running some tests against Onyx, but I'm not sure if we have a node currently running. @Nashatyrev is our guy on Onyx and can get back to you.
Pawan Dhananjay
@pawanjay176
thanks :)
Cem Ozer
@cemozerr
Hi @pawanjay176, I do have an Onyx node running on my end as well. How can I help? If you need the public IP address of our node to sync, it is: 18.188.234.215
Adrian Sutton
@ajsutton
@here Two important announcements:
  1. With the upcoming launch of the Altona testnet which uses v0.12.1 of the spec we'll be merging our v0.12.1 support into the master branch. Witti will continue to live on for a bit and is a useful testing ground as a testnet with some unique life experiences so for nodes that you're continuing to run on Witti use the 0.11.5-SNAPSHOT version. We don't yet have final config for Altona so I'll let you know the builds to use when that lands - it will be a 0.12.x release of Teku.
  2. We'll be moving the official Teku channel from here over to the new ConsenSys discord and we'd love you all to join us over there: https://discord.gg/Ve9sQAX This channel will hang around for a bit but will eventually be archived off.
Pawan Dhananjay
@pawanjay176
Hey @cemozerr I tried connecting to the node you gave..it gets connected and then immediately disconnects
would be helpful to know why it kicked me out
also, do you guys have support for noise?
Adrian Sutton
@ajsutton
@pawanjay176 My guess is it had reached its peer limit (goodbye reason would be code 129). And yes we support noise.
Adrian Sutton
@ajsutton

Teku v0.11.5 has been released. This is the last release that is compatible with the v0.11.x beacon chain spec and support for the v0.12.1 spec has now been merged into the master branch. If you are using Teku with the Witti testnet, please use the 0.11.5 release and stop pulling in updates from master.

There may be some last minute changes to the Altona testnet configuration but the 0.12.0-SNAPSHOT builds and master branch of Teku will support it and the final config should be merged in within the next couple of days.

Don't forget to come join us in the #teku channel on the ConsenSys discord server: https://discord.gg/Ve9sQAX

Pawan Dhananjay
@pawanjay176

@pawanjay176 My guess is it had reached its peer limit (goodbye reason would be code 129). And yes we support noise.

yes that might be it

also, i am consistently getting stream timeouts on my metadata requests..any idea what that might be?
Phistr90
@Phistr90
Hey guys, I have just noticed that teku cant deal with "~" as relative shorthand for home directory. results in a lot of fancy stuff like creating a folder named "~" etc. would be great if you could fix that
Phistr90
@Phistr90
Also please make it possible to generate the tx data for the deposit only. I dont want to send it on the same device for security reasons esp I dont want to provide the pk.
and for the generate-and-send it would be nice to get any feedback, eg tx hash...
You dont get any feedback whether the deposit was successful whatsoever
Phistr90
@Phistr90
Also please show during start which validators will be used and their status.
Adrian Sutton
@ajsutton
@Phistr90 This is common behaviour when you use the = form of arguments because the shell is actually responsible for expanding ~ and it can't see it in the middle of an argument. So --data-path=~/foo won't expand the ~ but --data-path ~/foo will.
Adrian Sutton
@ajsutton
https://github.com/PegaSysEng/teku/pull/2258/ looks like it should improve the output of the validator commands. Note that you don't have to use Teku's built-in commands to generate validator keys, we load a EIP-2335 keystore so any tool that can generate that can be used for creating keys and sending deposits.
In my ideal world each client wouldn't have to implement their own version of deposit sending tools and common software would just be used to do it. My ideal world isn't panning out quite as I would have liked though so we will likely need to do another round of improvements to our validator subcommands to make them easier to use and things like supporting sending the deposit via a separate wallet would definitely make sense.
The list of validators being run by the node is currently logged by default to the log file but not the console. I've created PegaSysEng/teku#2260 to send this to the console and include the validator status (as best we know given when we first start we will likely be out of sync)
Adrian Sutton
@ajsutton
Thanks for the feedback @Phistr90 it's very useful.
And while I'm here, another reminder that we moving over to the #teku channel on ConsenSys discord: https://discord.gg/Ve9sQAX Would love you all to join us there.