Ethereum.phone for Light client

Ethereum.phone for Light Client
Simple Roadmap
L4

Inspiration

At a time when decentralization has become more important as Eth2.0 becomes PoS , the project aims to lower the barriers of the general public's blockchain with mobile devices that are faithful to decentralization and added to blockchain functions by operating nodes on inexpensive devices

What it does

Along with Embedded Light, Eth node will be created with Ethereum Phone to contribute to the Ethereum ecosystem that pursues decentralized nodes. It aims to implement a staking node in a low cost/low power Ethereum Phone for eth2.0 switching to PoS.

How we built it

Challenges we ran into

Accomplishments that we're proud of

We have set up and operated the Geth Embedded Light Node, and we have been designing and producing custom Embedded Light Node. In order to develop an Ethereum Phone that can operate eth node in the form of a Blockchain Phone, we are currently developing a Blockchain Phone by purchasing Galaxy S8/Samsung Exynos8895 Development Board, Mate 10/ Huawei Kirin970 Development Board, and One Plus 5T/Qualcomm Snapdragon 845 Development Board.

What's next for Ethereum.phone for Light client

Light Client development, which utilizes basic WiFI , is expected to take three months in development mode. The development period is estimated to be about one year before optimizing the mobile communication modem interface(RIL), launcher, and OTA OS Update, and the long term road map will be prepared and carried out.

*RIL: Radio Interface Layer *OTA: Over The Air

What we learned

( ETH2.0 Clients Mentoring Session w/ Korean Hackathon teams

Date & Time : 18:00 - 19:00 (KST), 11 Dec 2020

Mentor: Zahary, Nimbus team lead

Team 1: Delta

One-pager: https://drive.google.com/file/d/1jfXZbPRmmVe_RXQCEJEu4HWRU9jijDLp/view?usp=sharing

Feedback:

The Nimbus team is targeting the desktop operating system (e.g.,Linux, Mac, Windows) at the moment. But we’ve tried to implement Nimbus on mobile devices (e.g., Android) running Nimbus as a native application (NDK).

Should learn and focus on 2 main areas to learn ETH2.0 clients. First, networking: how to get information from the network?(e.g., Gossip protocol, libP2P) and Second: cryptography: Merkle proof. Should understand how Ethereum uses cryptography(Merkle proof in particular). The team should be separated into 2 parts for each of the areas.

I wish the team could work on this project for the next 3 months. We’d like to help move this initiative forward.

Questions:

1) For faster light clients, what features should we consider that are good for implementing FPGA and ASIC?

ETH2.0 spends most of its time to verify the PoS signatures, the public key that multiple signers share signatures. A lot of validators can sign something without increasing the size of the signature. The PoS definitely optimized the energy consumption of devices and efficiency of the network. But as it is using so brand new crypto schemel, ETH2.0 doesn’t have the best hardware implementation yet, so difficult to optimize for hardware libraries. But we will work on hardware implementation of PoS. Also SHA-256 should be optimized for processors.

2) What workflow should we follow to implement the Light Ethereum 2.0 client?

Someone for the networking side, Someone for the cryptographic side. The work should be divided into 2 parts.

3) What designs did the Nimbus Light Client consider to securely store or use private keys?

each validator in ETH2.0 has 2 keys. 1) withdrawal key - will be used when you exit the network or withdraw your deposit (the withdrawal will be made available in the future). It should be stored safely. You should store it in a cold storage 2) validator signing key - will be derived automatically from the withdrawal key. You should back up a mnemonic phrase matching the withdrawal key. The signing key will be generated based on this mnemonic. To keep your signing key used, you should store your signing key on the server (file system). Hackers can steal your signing key. For better security, you can ask for a password for every transaction but it can result in software downtime. You can also store your key as a JSON according to the standard projected by a password. You can also make your keyfile accessible only by a specific user in your OS.

4) What were the most difficult things when designing and developing Nimbus? Handling the Merkle proof and other cryptography was difficult. Also the network is not deterministic sometimes. Ethereum itself is an interesting technology so tackling the challenges is worth it.

5) What are your expectations for 'Storage' and 'Memory footprint'? The Nimbus client uses the lowest memory at the moment so it is very competent in this area. Nimbus uses 1 GB of RAM while others use more than 3 GB of RAM. We are targeting to reduce it to less than 500 MB of RAM. Regarding the storage, all the clients require a lot of storage but the team is working on minimizing the storage usage. The ETH2.0 protocol allows you to discard some old storage. Unlike ETH1 clients, ETH2 clients can be run on almost constant storage usage.

6) Is it possible to implement a light client on an 'embedded board using Cortex-M4(similar to Raspberry Pi)’?

We are actively working on implementing Nimbus on Raspberry Pi.

7) Which language should I learn and implement for light clients development generally? Such as C/C++, or Python

I would say that Nim is great to learn and implement ETH2 clients. You can think of Nim as a combination of C++ and Python. You get the speed, and memory usage of C++ (you can compile your code with a C compiler). But the syntax is very similar to python so it is very easy to learn and read, and it offers high level abstraction and APIs. But If have to choose between C++ and Python, I would choose C++ to minimize computing resource usage

)