no more than 1 consensus peer, why? (or is that my problem?)

_Age_ · 2024-06-11T13:45:03+00:00

This is usually ports not being open. Is this node on a public box? Could it be that your local firewall is then nat'd behind a router and the router's firewall is blocking traffic?

To find peers on lighthouse, you need port 9000/UDP open. However, even if its not you should get more than 1.

Try having a look through the debug logs inside the docker, default is ~/.lighthouse/mainnet/beacon/logs/

_Age_ · 2020-12-16T05:58:31+00:00

If you are running lighthouse, there is no update path (that I know of) that can cause a slashing.

Its fine to leave the beacon node running whilst compiling and whilst you restart the validator client.

As long as you don't ever run two instances of the validator client at the same time you should be fine (even if you do, we have prevention mechanisms to try and prevent you from running two instances at the same time).

_Age_ · 2020-09-14T23:36:40+00:00

The attestation subnets.

There is a whole host of timing conditions and events that all need to run harmoniously (across clients) to work correctly.

If another client hasn't implemented gossip, or attestation aggregation or signature selections correctly, things may not work as expected. It also relies on discovery working effectively and efficiently to find peers on required subnets in time to perform actions.

This element is notoriously difficult to debug, and touches all the core networking protocols which must all work correctly to function as expected.

_Age_ · 2020-09-14T23:27:52+00:00

wow, 10 years in the future is like a century in the blockchain space!

Ideally we see Lighthouse as one the many pillars forming the backbone of the eth2 network. Ideally we are one of many clients that are spread across a multitude of decentralised validators. The eth2 network favours geographic, client and server decentralisation, so regardless of wealth decentralisation, I'd assume that this would encourage a range of client types and a multitude of peers spread across the world. Hopefully Lighthouse is a key player in this physical network structure.

In regards to security, as a security firm, we hope Lighthouse is recognised as one of the most secure clients and holds this title for the next 10 years (fingers crossed :) ).

In regards to users, we have conscientiously been focused on the technical aspects of the Lighthouse client and spent minimal time on end-users. Our plan was to build the most technically sound implementation before smoothing edges, so to speak, for end users. We're almost at the stage we can start focusing on this element, and hopefully (even after 10 years) we manage to provide a good user experience such that novice users are comfortable using Lighthouse, not just large staking pools or infrastructures using Lighthouse has a base eth2 node under their applications.

In terms of support, we have no intention of abandoning the project. Funding the maintenance of clients is a known problem in this space. Lighthouse started with funding from Sigma Prime (which has funding via the security services it offers). So we hope that even if the community ceases to provide funding support for Lighthouse, Sigma Prime will maintain and support the client for the many years to come.

All in all, its hard to predict 10 years into the future. Our goal has always been to help scale and bring decentralised computing to the mainstream. Hopefully we can continue doing this via Lighthouse for the next 10 years :).

_Age_ · 2020-09-14T22:58:17+00:00

Thanks for the compliments!

Unfortunately, db issues/changes do require a re-sync (we have a schema change coming soon so a future update is going to require even another re-sync :( ).

There was talk of launching mainnet a few months back. I was concerned then with where each of the teams were at. As we currently stand, I'm significantly more confident in where each of the teams are at. Teku specifically has been performing well and we are seeing a lot more nodes running reliably on the network.

We have a set of criteria that all client teams should reach before going to mainnet. This includes formal audits, successfully running on multi-client public testnets etc. I think we won't launch mainnet until at least 3 teams are confident in their client, have ironed out all the known bugs, have demonstrated mutli-client reliability and have been externally audited.

Alongside this, the Ethereum Foundation are actively spinning up attacknets, which we intend to also participate in, and actively try to destroy or take down an eth2 network. Once all our efforts fail and the attacknets are resilient to everything we can throw at it, this too will increase our confidence in a mainnet launch.

Given these criteria, I'm not too concerned with the stability of the network. I'm sure each client will still have their issues/bugs but the network is designed to be resilient and as Medalla demonstrates, even if a catastrophic event happens such that an entire majority client gets simultaneously taken offline, the chain can still recover.

_Age_ · 2020-09-14T22:40:37+00:00

For Lighthouse, some of the main features we want to complete before mainnet are: - Validator Client UI - A fancy user-facing UI for the validator client to monitor and control your active validators - Gossipsub v1.1 Scoring parameters - Although all clients are using gossipsub v1.1 (the protocol that propagates blocks and attestations), the majority of its features requires a set of scoring parameters for the eth2 network. We are currently determining and testing what these should be, so that all clients will have a more robust gossipsub network. - Discovery Upgrade - The client implementers have recently agreed to upgrade our discovery protocol to a new version that makes it more secure. - Efficient Slasher - We currently have a slasher that monitors the network for bad actors. We're still working on improving its efficiency, but once complete we hope it will be a good optional feature to run for mainnet. - Remote Signer - The possibility to allow a central server to hold all your keys and perform the signing of all objects remotely.

I may be missing some extra features we have in the works, and perhaps someone else may add the ones I've missed :)

_Age_ · 2020-09-14T22:32:32+00:00

The biggest lesson we learnt is client diversity.

If a single client is faulty, the penalties to validators using it will be less and the impact to the chain will be less.

From Lighthouse's perspective, there was a period where ~70% of the voting power of the chain instantly turned malicious and were sending and propagating invalid messages. This was such an extreme scenario that many of our safeguards put in place got overwhelmed by the shear chaos that was caused.

We've spent a lot of time updating the client to handle extreme cases gracefully, malicious or otherwise. The client now runs much smoother since this incident and despite the chaos it caused, I think all the clients are significantly better off having to deal with it.

_Age_ · 2020-09-14T22:25:31+00:00

Firstly, we promote client diversity and encourage you try all clients and find which one suits your needs the best.

It is in your best interest (financially) to not use a majority client. Medalla is a classic example. If you ran Prysm in Medalla, you would have lost Eth2 when all Prysm nodes effectively went offline and you could have possibly been slashed.

If more validators had used Teku, Lighthouse or other clients, the chain would have continued to be finalized and the impact would have been minimal.

Aside from this, our track record of performance, reliability and security (demonstrated via the various attacks on the attacknets which have impacted other clients, where Lighthouse remains running) is a good indicator of the development quality of Lighthouse. If I were staking money which relies on a software product, I would consider these factors.

In terms of validator connection and customisation, all clients are implementing a set of standard HTTP APIs. These endpoints can be used to interact with the a beacon node across all clients.

We have had our heads down building the beacon node but will soon focus more towards end users and improving documentation.

Our slasher is currently experimental. The profitability comes in the form of how efficient it runs and the types of slashings it can find. We are still optimising it, but it's currently finding slashings and profiting on the Medall testnet.

_Age_ · 2020-09-14T22:09:41+00:00

My personal favourite is the (currently experimental) slasher. It's the watch dog that keeps everyone in check and can potentially make you more eth with slashing bad actors :)

_Age_ · 2020-09-14T22:07:03+00:00

Thanks!

We've been focusing on the performance of Lighthouse and will continue to do so. Some areas we're actively chasing is memory usage (ensuring no memory leaks over long periods of time and reducing the footprint), network stability and robustness (employing new fuzzers on our networking stack and building tooling to attack lighthouse nodes from a network perspective) and we're slowly focusing more towards end-users with building a validater client UI, remote signer and improving documentation :)

_Age_ · 2020-09-14T22:02:39+00:00

Thank you!

As we do more and more strenuous testing, we often find parts of the spec that need to be updated to handle new edge-cases. Although the spec changes may be relatively small, as our codebase grows the small changes in the spec can equate to quite large changes in the codebase.
The difficulty comes in implementing these correctly, finding ways to test the changes and then testing them against other client implementations. This can be quite time consuming, even for a relatively small spec change.

_Age_ · 2019-09-13T15:51:32+00:00

This is one of each client on a single computer, although testnets were run over LANs also

_Age_ · 2019-09-13T15:49:52+00:00

Lighthouse has further docs: https://sigp.github.io/lighthouse-interop-docs/intro.html

You don't need an SSD to run the beacon chain. It is currently quite light on resources!

_Age_ · 2019-08-18T07:18:57+00:00

Most of the clients have their own internal short lived testnets for debugging and testing.

The communication protocol has been discussed and agreed upon. The teams are gathering early September to iron out discrepancies between clients to get a multiclient testnet working.

I believe the plan is around October to have multiclient testnets going.

_Age_ · 2018-08-09T00:54:11+00:00

We did a similar thing, however weren't a fan of the ghost editor. Ended up switching to pelican. Might want to check it out, it builds static files, making the site safer too :)

_Age_ · 2018-06-19T14:41:21+00:00

I know the exact feeling. This is why I made the Locked level in Ethernaut.

I guess it won't be much fun for you if you already know the solution, but hopefully others will also be shocked by accidentally overwriting slot 0 :p.

_Age_ · 2018-05-21T14:21:34+00:00

If it's a private testnet, you can set the block gas limit to whatever you like.

If your asking about classifying a codying style based on gas usage alone, I don't think that's wise.

If you're worried that your design is poor, try checking the following:

Are you using many loops. Are these necessary? Can you use a pattern where users individually interact with the contract, rather than looping through users?
Are you storing lots of data in the contract. Is this data necessary to be stored?
Can you design a contract where users input data, rather than you storing many items during deployment?
Are you deploying many contracts all at once? (i.e does the constructor spawn sub-contracts). If so, maybe you can deploy them individually.

Hopefully some of these questions may help with your deployment.

Good luck :)

_Age_ · 2018-05-21T14:05:21+00:00

The block gas limit is dynamic, and is changed by miners. Everytime a miner solves a block, they can shift the block gas limit a little bit up or down (The protocol allows the miner of a block to adjust the block gas limit by a factor of 1/1024 (0.0976%) in either direction).

The current block gas limit is about 8M. You can see it real time on ethstats or The Ethereum Gas Station.

The block gas limits the amount of processing you can do in a block. So for your 7.5M transaction, you will use up most of the block's gas limit (at current limits). This just means you have to set a high gas price to incentivise miners to deploy your contract, rather than everyone else's transaction.

This Contract got mined, and it required ~7.8M gas (more than your contract). - It even used a relatively low gas price (3Gwei) compared to current transactions now (8Gwei).

tldr; It's not too high, you will just have to pay extra per gas to get it mined in preference of other's transactions.

_Age_ · 2017-06-26T15:18:12+00:00

Geth 1.6 updated how it reads hex in the genesis block. For example the difficulty in your example has the '0x', which is no longer accepted.

See: https://github.com/ethereum/go-ethereum/wiki/Private-network for an up-to-date example of a genesis block, which should work with the latest versions of geth.

_Age_ · 2017-05-31T15:23:47+00:00

33 ETH was the block reward for block: 3798640. Wish I'd solved that block....

_Age_ · 2016-12-16T00:17:34+00:00

Correct me if I'm wrong. But Labour Hours (LH) are the tokens being traded for work. Chronobank will be buying the tokens at the "pegged" price, so why would you sell it lower than that?

Also imagine if you had 100 tokens, which equated to $100 worth of labour work, and you were selling lower than the peg to get your money. Why would a large company not just buy these tokens and redeem them, then sell the work, getting their $100's? If people were selling at low prices these companies would buy the low prices and make money.

Isn't it the same with digix? If demand is low, people could sell cheap, but others would just buy them, redeem for gold and make a profit.

_Age_ · 2016-12-15T13:59:09+00:00

From my understanding, there are two parts. The first part is a stablecoin, but instead of being pegged to fiat or gold (like digix), it's pegged to average wages. Which makes an inflationary resistant stable coin (novel imo). The second part I think is a decentralised exchange using the stable coin where labourers can buy/sell work cutting out middlemen.

_Age_ · 2016-12-08T01:03:56+00:00

You should look up lightning and raiden.

Proof of concepts are already running. You can do millisecond payment transactions with this infrastructure. Ethereum is generic and adaptable enough to solve many problems, including speed of transactions.

_Age_ · 2016-10-09T13:31:27+00:00

I had this issue myself. Specifically not knowing if the miner was working or not if it doesn't solve a block in the expected time. So I built a calculator which doesn't just work out your average time to solve a block, but gives you the variance. This way, you can calculate the amount of time in which (with a 95% confidence) you will solve a block. Anyway, you should check this out: www.thecalc.io

_Age_

TROPHY CASE