Porting Ethereum – Tizen cross-builds. Update by Anthony Cros, 5th November 2015

20151103_165153

We are still working on 2 fronts in parallel, the webthree (C++) implementation (formerly known as cpp-ethereum) and the go-ethereum (Golang) one.

go-ethereum (Golang)

Block synchronization problem

Not much progress on that front beside confirming an issue that seems to occur with ARM builds regarding block synchronization (see previous post). It seems other people have reported the same issue and hopefully the devs will figure it out soon.

LES sub-protocol (light client)

We are also waiting for the LES sub-protocol to be finished, which according to the latest update (see “Light client/mobile” section) is making good progress.

web-three (C++)

Cross-compilation

A lot of work has been put into cross-compiling the C++ implementation, and after a lot of sweat I finally produced a binary to test out! Unfortunately it results in a good o’ segfault for the moment. I have informed the devs of it and am waiting for their feedback. It may be an issue with the CryptoPP library, which is actually due for removal (see Gavin’s comment on the matter).

Code

We are making the process of producing this binary open for anyone to try out (see our Github repo).
There exists a Dockerfile that can be used as basis, although it is not finalized yet. Still, a basic Ubuntu 14.04 image to which the packages listed in the Dockerfile are added should provide the right environment to run the scripts above.

Documentation

I have also spent some time on improving upon the devs’ representation of the various dependencies involved in building eth. I started from the original DOT file:
BwKjPZ6
and added information I gathered from compiling from source myself as well as various comments from the devs:

dot

which results in

rauzXbx

It is still a work-in-progress but we will hopefully have a good overview of all these dependencies soon.

Stay tune for more progress!

Porting Ethereum – Tizen cross-builds. Update by Anthony Cros, 14th October 2015

NOTE:   You can follow along with our day-to-day progress on the Ethereum Porting Gitter channel.


Ethereum_logo_bwlogo-Tizen-Pinwheelanthony-cros

Some progress! On both fronts: go-ethereum and cpp-ethereum.

Our efforts lately have been focused on cross-compiling these two projects targeting an ARM architecture.

go-ethereum

The easier one first. As Bob mentioned in his latest post, Péter Szilágyi from the go-ethereum team has created the great xgo tool, that allows cross-compiling go-ethereum to different platforms (though it is not limited to cross-compilation for Ethereum, it is a general tool).

Using xgo and the instructions from its README file, I was able to generate a binary for geth quite easily and without any change (xgo notably leverages the power of Docker).   I was then able to run this binary on a Samsung TM1 developer phone (with Tizen O.S.), a process I will detail in an upcoming post. The binary worked well up until a point during block synchronization (~block 90K) where it failed, though nothing indicated it was an issue with the platform itself (more likely the particular version of geth I had used for compilation). I will rebuild and report on the result soon!

tony:~/tizen-sdk/tools[130] $ ./sdb push ~/.tony/program/go/go1.4.2/bin/geth-linux-arm /home/developer
pushed geth-linux-arm 100% 19MB
1 file(s) pushed. 0 file(s) skipped.
/home/tony/.tony/program/go/go1.4.2/bin/geth-linux-arm 4142 KB/s (20639213 bytes in 4.865s)
tony:~/tizen-sdk/tools[0] $ ./sdb shell
sh-4.1$ cd /home/developer/
sh-4.1$ ls
geth-linux-arm testupload.txt
sh-4.1$ ls -l
total 20160
-rwxr-xrwx 1 developer developer 20639213 Sep 29 18:49 geth-linux-arm
-rwxrwxrwx 1 developer developer 0 Jul 3 16:55 testupload.txt
sh-4.1$ ./geth-linux-arm
=======================================
Disclaimer of Liabilites and Warranties
=======================================

THE USER EXPRESSLY KNOWS AND AGREES THAT THE USER IS USING THE ETHEREUM PLATFORM AT THE USER’S SOLE
RISK. THE USER REPRESENTS THAT THE USER HAS AN ADEQUATE UNDERSTANDING OF THE RISKS, USAGE AND
INTRICACIES OF CRYPTOGRAPHIC TOKENS AND BLOCKCHAIN-BASED OPEN SOURCE SOFTWARE, ETH PLATFORM AND ETH.
THE USER ACKNOWLEDGES AND AGREES THAT, TO THE FULLEST EXTENT PERMITTED BY ANY APPLICABLE LAW, THE
DISCLAIMERS OF LIABILITY CONTAINED HEREIN APPLY TO ANY AND ALL DAMAGES OR INJURY WHATSOEVER CAUSED
BY OR RELATED TO RISKS OF, USE OF, OR INABILITY TO USE, ETH OR THE ETHEREUM PLATFORM UNDER ANY CAUSE
OR ACTION WHATSOEVER OF ANY KIND IN ANY JURISDICTION, INCLUDING, WITHOUT LIMITATION, ACTIONS FOR
BREACH OF WARRANTY, BREACH OF CONTRACT OR TORT (INCLUDING NEGLIGENCE) AND THAT NEITHER STIFTUNG
ETHEREUM NOR ETHEREUM TEAM SHALL BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR
CONSEQUENTIAL DAMAGES, INCLUDING FOR LOSS OF PROFITS, GOODWILL OR DATA. SOME JURISDICTIONS DO NOT
ALLOW THE EXCLUSION OF CERTAIN WARRANTIES OR THE LIMITATION OR EXCLUSION OF LIABILITY FOR CERTAIN
TYPES OF DAMAGES. THEREFORE, SOME OF THE ABOVE LIMITATIONS IN THIS SECTION MAY NOT APPLY TO A USER.
IN PARTICULAR, NOTHING IN THESE TERMS SHALL AFFECT THE STATUTORY RIGHTS OF ANY USER OR EXCLUDE
INJURY ARISING FROM ANY WILLFUL MISCONDUCT OR FRAUD OF STIFTUNG ETHEREUM.

Do you accept this agreement? [y/N] y

I1004 23:21:26.410705 9630 flags.go:414] WARNING: No etherbase set and no accounts found as default
I1004 23:21:26.411956 9630 database.go:71] Alloted 16MB cache to /home/developer/.ethereum/chaindata
I1004 23:21:26.454467 9630 database.go:71] Alloted 16MB cache to /home/developer/.ethereum/dapp
I1004 23:21:26.475128 9630 backend.go:291] Protocol Versions: [62 61], Network Id: 1
I1004 23:21:26.476165 9630 backend.go:333] Blockchain DB Version: 3
I1004 23:21:26.480377 9630 chain_manager.go:248] Last block (#0) d4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3 TD=17179869184
I1004 23:21:26.546630 9630 cmd.go:125] Starting Geth/v1.2.0/linux/go1.5.1
I1004 23:21:26.547729 9630 server.go:311] Starting Server
I1004 23:21:26.568572 9630 udp.go:207] Listening, enode://95b46a352806ebd5e97ec6bdcdcb9ea425eed48c95f78963df264c9985cba1aa72c658482951025322a8db49b88ae3eeb2314a0995df8d636de0276259bdaa5b@108.162.185.124:30303
I1004 23:21:26.569580 9630 backend.go:559] Server started
I1004 23:21:26.570892 9630 ipc_unix.go:109] IPC service started (/home/developer/.ethereum/geth.ipc)
I1004 23:21:26.571563 9630 server.go:552] Listening on [::]:30303
I1004 23:21:26.574707 9630 nat.go:111] mapped network port udp:30303 -> 30303 (ethereum discovery) using NAT-PMP(192.168.1.1)
I1004 23:21:26.588775 9630 nat.go:111] mapped network port tcp:30303 -> 30303 (ethereum p2p) using NAT-PMP(192.168.1.1)
I1004 23:21:36.715515 9630 downloader.go:275] Block synchronisation started
meanwhile:
sh-4.1$ pwd
/home/developer/.ethereum
sh-4.1$ find
.
./nodes
./nodes/000001.log
./nodes/LOCK
./nodes/LOG
./nodes/MANIFEST-000000
./nodes/CURRENT
./geth.ipc
./nodekey
./chaindata
./chaindata/LOG.old
./chaindata/MANIFEST-000008
./chaindata/LOCK
./chaindata/000010.ldb
./chaindata/LOG
./chaindata/CURRENT
./chaindata/000007.log
./dapp
./dapp/000002.log
./dapp/MANIFEST-000003
./dapp/LOG.old
./dapp/LOCK
./dapp/LOG
./dapp/CURRENT
sh-4.1$ find -type f | tr "\n" "\0" | du -cs --files0-from=-
1392 ./nodes/000001.log
4 ./nodes/LOCK
8 ./nodes/LOG
8 ./nodes/MANIFEST-000000
8 ./nodes/CURRENT
8 ./nodekey
8 ./chaindata/LOG.old
8 ./chaindata/MANIFEST-000008
4 ./chaindata/LOCK
1892 ./chaindata/000010.ldb
8 ./chaindata/LOG
8 ./chaindata/CURRENT
892 ./chaindata/000007.log
4 ./dapp/000002.log
8 ./dapp/MANIFEST-000003
8 ./dapp/LOG.old
4 ./dapp/LOCK
8 ./dapp/LOG
8 ./dapp/CURRENT
4288 total

cpp-ethereum

Much more manual work here, but after much struggle I was able to successfully cross-compile the libweb3core library. I created a set of scripts that should allow anyone to reproduce this process (in fact please do and report on any issue encountered!).
For it to work, I had to use a number of hacks along the way however:

  1. code – Hardcoding Boost‘s project-config.jam file to use my gcc cross-compiler (I tried many different flags/environment variables for bootstrap.sh but none ever worked/were picked up)
  2. code – Commenting out the CXXFLAGS-march=native flags from CryptoPP‘s Makefile. Likewise I found no cleaner way to unset this flag (which you must for it to succeed).
  3. code – I was never able to get the ARCHIVE_INSTALLS_DIR flag to get picked up during configuration for JsonCpp, instead having to rely on DESTDIR during the installation phase (not necessarily a big issue, but still frustrating)
  4. I ended up having to create a ~/$HOME/cryptopp symlink to CryptoPP’s installation directory for libweb3core‘s CMake file to be able to detect CryptoPP’s headers, no other combinations ever seemed to work. This on top of making CMAKE_INCLUDE_PATH point to the source directory. Removing either results in a failure to detect said headers (note that no such issue occured for the detection of the library itself).
  5. code – Disabling of MiniUPNP, which has apparently broken backward compatibility in its latest version and for which I wasn’t able to find a working version (typically because of failure to include upnp-dev.h, which would have also required hacking their CMake file).
  6. code – Removal of erroneous -lOFF artifacts from the CMake configuration phase of libweb3core, a bug I have brought to the attention of the cpp-ethereum team.

If anyone is aware of workarounds for these or can even suggest a more straighforward/correct way of getting to the same result, please contact me on gitter.

So overall it’s quite a lot of pieces that need to work together in order to create such a binary. Next step will be building other necessary components for eth to run. After which I will hopefully be able to test the C++ client on the same Z3 phone!

Stay tuned for more progress!

Porting Ethereum – Native build on Tizen emulator (dead-end) – by Anthony Cros

So as Bob mentioned in his yesterday’s update, I tried to build natively on the Tizen emulator (available as part of their SDK). Unfortunately this proved to be an dead-end (see the full story below).

We still thought we’d describe what our process was, as that might help someone down the road and/or convince the Tizen people to make this process possible in the future. After all it’s a pity to have a Linux flavor that can’t build anything natively… Why not stick to Android then?

So first step is installing the SDK (network install or local image-based install, either are fine).

This basically creates 3 folders (assuming a *NIX-based system here):

  • ~/.installmanager_2.3.1
  • ~/.tizen-sdk-data
  • ~/.tizen-sdk

The last one is the most interesting one. The first two are essentially there for storing logs of the SDK installation and the emulator data and logs. The tizen-sdk dir (A.K.A SDK_PATH in scripts) is a pretty massive folder (~6GB), which contain files for the emulator, IDE (Eclipse spin-off) and libraries/toolchains for the various platforms and architectures.

The emulator can be found under ~/tizen-sdk/tools/emulator, and the bin/em-cli in it is what I used to get the emulator running (note that there’s also a UI in it, but it died on me consistently). So with it you can do a few interesting things:

  • ./em-cli list-image, which lists the base images available: x86-standard / mobile-2.3.1, x86-circle / wearable-2.3.1, x86-standard / wearable-2.3.1
  • ./em-cli create [...], to create such a VM (see below for details)
  • ./em-cli launch [...], to launch VMs
  • ./em-cli delete [...], to delete VMs

Note that em-cli -h gives you all the actions possible, while em-cli -h <ACTION> gives you help on a specific action (e.g. em-cli -h create)

So you can create a VM called mytizenvm like so:

./em-cli create -n mytizenvm --base-id 2

The value for --base-id corresponds to the ID field from the list-image command above, in this case corresponding to x86-standard / wearable-2.3.1 (ID 2). This should return Success: To create new Virtual Machine is completed. (sic). The data is stored under ~/tizen-sdk-data/emulator/vms/mytizenvm by default (where you’ll also find logs).

The content of ~/tizen-sdk-data/emulator/vms/mytizenvm is as follow:

$ file *
logs:                    directory 
emulimg-mytizenvm01.x86: QEMU QCOW Image (unknown version)
swap-mytizenvm01.img:    QEMU QCOW Image (unknown version)
vm_config.xml:           XML document text

So really just a QEMU image and a config file.

Next up is launching the VM:

./em-cli launch -n mytizenvm

You can see the logs under ~/tizen-sdk-data/emulator/vms/mytizenvm/logs. By now you should see something like this pop up on desktop environment:

watch

Note that the button on the right-hand side is clickable and that right-clicking on the watch image itself gives you access to a contextual menu. Also, closing the watch cleanly has never worked for me, I always had to Force Close it (in Advanced sub-menu of the contextual menu).

From here, we want to open a shell in order to access the emulated device: use the Shell option in the contextual menu, this will pop-up your default terminal (gnome-terminal in my case). Tadah! You are now in the Tizen system.

On it:

  • you are the developer user, whose home dir is /home/developer
  • you can become root: su - root
  • you can setup a shared directory with your “host” machine (the one you started the emulator with), by default under /mnt/host on the device (right-click> Control Panel > Device Manager > Host Directory Sharing). Note that the /mnt/host is owned by the system user.
  • you can see what ports are open: netstat -tulpn
  • you have access to a few very basic binaries under the usual bin folders (see echo $PATH for complete list)

But in order to build either geth or eth, ones needs to… be able to build in general! And this is were things get rough. There is no make. So we should try and build it! But… there’s no gcc to build it either! So we need to build gcc itself… So it means having to go through these steps.

There is also an rpm binary available however, and http://download.tizen.org/snapshots/tizen holds many RPM files. I poked around at it but was unable to get anything useful out of that binary (it lacks both -bb and --rebuild options for one thing).

So at this point, I decided to get help on the Tizen forum, and Bob pinged one of his contact on the Tizen side. And then we were basically adviced to give up that route and to stick to cross-compilation (see Tizen native builds section of Bob’s post for the specific answer).

So now… off to cross-compilation wonderland instead (luckily the SDK setup will be useful here as well)!

Porting Ethereum to mobile Linux

02 hotel porter_std

Last week the ETHDEV team made the decision to implement Ethereum Light Client as a sub-protocol, rather than as part of the main protocol.   The decision makes sense, to manage risk, and to separate concerns, but it delays things.   Probably by about “two weeks”.

It is going to take some time for the dust to settle and for the client implementations to get back to working proof-of-concept on that still-to-be-defined sub-protocol.   So Anthony and I are going to go off on a tangent for the time being, and focus on porting the existing full-node clients (both eth and geth) to all of the mobile Linux platforms of interest.

A new Ethereum Porting Gitter channel has been created, which I have written this “state of play” article for.

We are going to work on the following platforms and devices:

Form factor Device OS Version
Developer phone Samsung RD-PQ Tizen 2.3.0
Smartphone Samsung Z1 Tizen 2.3.0
Smartwatch Samsung Gear S2 Tizen 2.3.1
Developer phone Samsung TM1 Tizen 2.4.0 Beta
Smartphone Samsung Z3 Tizen 2.4.0
Smartphone Jolla Phone Sailfish 2.0
Smartphone (future) Intex Aquafish Sailfish 2.0
Tablet (future) Jolla Tablet Sailfish 2.0
Smartphone Meizu MX4 Ubuntu Edition Ubuntu Touch ??.??

John Gerryts has been doing a very similar task for the last few months as part of a DEVGrant for EthEmbedded.   His focus so far has been on compiling on-platform.   This challenge has mainly laid in broken dependencies and in working through oddities in the specific platforms.   The SBCs are all “just” Linux distros.

Mobile operating systems are rather different beasts than the capable little general computers which John has been porting Ethereum to.   Mobile devices have usually been designed for running applications on, not building and developing applications on.   There has been a major asymmetry between the power and specifications of desktop machines and mobile devices.  There still is some asymmetry, but the gap is closing fast.

You don’t develop iOS applications on an iPhone.   You develop them on a Mac with a cross-compiler.    You don’t develop Android applications on an Android phone.   You develop them on a PC, Mac or Linux box with a cross-compiler.   Most mobile devices have never had enough memory or processing power to build anything substantial.    The setup has been very similar to that which I have used for the majority of my professional development career building PlayStation and XBOX games.   You develop on a desktop machine and build binaries to transfer to the target machine and then use a remote debugger.

That time is coming to a close.   We are seeing a convergence across all device form-factors.   All computing devices are good now.   They nearly all have multiple cores, decent amounts of memory, network connectivity, ARM or x86 SoCs and are all much-of-a-muchness in their “form”.    There isn’t much reason left why you wouldn’t use your phone for software development, or even your watch in a few years time.   I want to push the envelope on that, which is why I asked Anthony to start with looking at native builds on these devices.    That didn’t work so great for Tizen, and he will blog about that, but it looks to be a workable approach for Sailfish and Ubuntu Touch, which are very “normal” Linux distros.

Tizen native builds

Raster says:  Tell him to cross compile.  Tizen 2.x on things like emulator is for running tizen apps and nothing more.   You will not fix tizen 2. All devices locked down. No root for you.  You could cross build a toolchain for $home  But you will need magic to get headers and other things working in home when the bins are in usr.  But rpms won’t help you. You need root.  Emulator not useful as its x86.  So you get gcc on it. Fine.  Bins you make won’t work on any shipping tizen device (worth noting).   Rpi2 or other boards are a better bet imho

Sailfish native builds

Carsten Munk says: I’d for most purposes recommend a chroot on the device for compilation. you can for most intents and purposes take the ARM target of sailfishos and chroot into it on device. we have a couple of funny package dependencies that if you start developing a little too hard, device won’t boot up, so 😉

Ubuntu native builds

Niklas Wenzel says: Every program available in the Ubuntu archives for the armhf architecture can be run on your phone (though you are going to run into issues with GUI programs). I’ve been compiling my stuff on my phone for quite some time now.  However, the cross-compilation setup for Ubuntu SDK apps is really straight forward and way more comfortable than any compilation on the phone itself.  Additionally, installing additional debian packages on the phone requires a writable system image which means that your phone can break when you install OTA updates in the future. (To prevent that, you can reflash the phone to its previous state with a read-only system partition but that also means that the additional packages you installed will be removed from the phone again.) You could also set up a chroot on the phone for compiling stuff though.

Cross-compilation of geth and eth.

Péter Szilágyi who works on Ethereum is also the author of xgo and has put together Wiki pages on Cross-compiling Ethereum and Ethereum on Android, as well as adding cross-compile targets into the go-ethereum makefile for us today.   That is all cross-compilation for go.   Niklas Wenzel was also kind enough to point us at his template for Go QML cross-compilation.

Cross-compilation of C++ for the eth client will be much simpler, given that C++ cross-compilation is the default for all of these mobile Linux platforms.

So lots of work to do.  Anthony is digging in.    When we have got everything working to the degree in which that is possible (native/cross * eth/geth * Tizen/Sailfish/Ubuntu) plus a few OS version variants, we can move on to look at where we are sitting compared to John’s SBC builds.    Hopefully we can get all of this work into some cohesive whole and maybe even upstream it all into the main C++ and go client repos.   We will see 🙂

I also want to set up an automated build farm for all of this hardware, using real devices, not emulators.   And maybe we can even do some automated testing too.

When all of that is done, I hope we will be ready to go with actual Light Client code-paths within those applications we can now build for so many different platforms.    We should also look at in-process execution for the go codebase (as already exists with libethereum) for inclusion within applications and on small IoC devices.

Stay tuned!

Go for mobile Linux platforms

In parallel with Anthony’s hands-on work digging into the protocols and the go and C++ client codebases, I have started investigating options for bringing the go codebase to new platforms.

The recent Go 1.5 release added support for Android and iOS.    There is a gomobile tool which can be used to generate Java and ObjC binding for go packages for integration into existing native applications, or to build standalone APK and APP files based on a generic application framework, for pure go applications on mobile.

At first, I thought it would be necessary to extend this support to include C++ code generation to bring go to mobile Linux platforms, but I am now of the opinion that just building the existing go client for these mobile Linux platforms might actually be entirely adequate – treating them purely as other Linux distros, rather than specifically as mobile platforms.   At the time of writing, that would result in full-node clients, but would be the basis for light client when that “mode” is available.   It would not support in-process go light-clients, but that isn’t currently a supported scenario anyway.

So … I will get going to compiling the go client for the various mobile Linux platforms (Sailfish, Tizen and Ubuntu Touch) which we are targeting.  The go client has been ahead of the C++ client for light client, and ultimately I think we are going to want both implementations (and more – Python, Java, Javascript) on all platforms they can reach.

I will be leaning on the work already done by EthEmbedded, because our mobile/wearable platforms are very, very similar to those embedded platforms – even sharing the exact same SoCs in some cases!

Ethereum Light Client update, Wednesday 9th September (by Anthony Cros)

Hi everyone,

Another update, since quite a lot has changed since last time!

The go-ethereum team is now actively working on a first version of light clients.  I guess that first version will handle the simplest uses cases, i.e. not taking part in securing the network.

cpp-ethereum devs have also mentioned on the newly created Ethereum Light Client Skype channel that they expect the newer protocols to be added to the C++ codebase within a few weeks (this will be needed for them to start working on light client capabilities).

In light of these changes, we are now offering our help to the go team to help speed up the development in any capacity we can. I had a Skype session with Zsolt Felföldi who is in charge of this task, and we agreed that if there was anything he could reasonably delegate to me, I would take it over (I’m now quite familiar with that codebase).

But as the The Mythical Man-Month posits, it may actually best to watch from the sideline until we can participate more efficiently.  Either way, all this is good news for those of us excited about light client support!

Stay tuned for more news in the weeks to come…

Ethereum Light Client update, Friday 21st August (by Anthony Cros)

Hi all !

Just a quick update on where we’re at.

anthony-cros

At this time we are still at the design phase, as the light client protocol isn’t finalized yet. While we are trying to anticipate on a few decisions, we will still need to be able to communicate with existing nodes in order to implement our use cases.

We have decided to favor a stand-alone module that would meet our immediate needs first (reminder that we are targeting smartwatches as our primary platform). The idea is that we would try and integrate this stand-alone module in the cpp-ethereum code base eventually by working with cpp-ethereum developers. Failing that, we still hope that our code base would at least serve as inspiration for them to add these capabilities (arguably crucial to boost adoption of Ethereum).

We have been in touch with the go-ethereum developers on our “light client protocol” gitter channel, as they are currently the most advanced implementation of the ETH wire sub-protocol. They have been very helpful in explaining some of the subtleties of the sub-protocol and keeping us up-to-date on their progress. I created a quick reference describing the most important changes it brings about.

I had created an initial and partial spec describing a naive approach to our mandate and that didn’t require any of the new PV6{2,3,4} sub-protocol functionalities. However in light of the imminence of their integration in the go-ethereum code base, we decided to scrap it and start a re-design that would leverage these messages instead, thereby greatly simplifying the work on our side (especially in regard to the need to traverse Patricia Merkle Trees – A.K.A. PMT or just “tries” – manually).

We will soon make this re-design available for the community to give feedback on.

See you next week for another update on the progress!

Anthony Cros