• Breaking News

    Monday, December 23, 2019

    Ethereum Vitalik: Alternative proposal for early eth1 <-> eth2 merge

    Ethereum Vitalik: Alternative proposal for early eth1 <-> eth2 merge


    Vitalik: Alternative proposal for early eth1 <-> eth2 merge

    Posted: 23 Dec 2019 08:23 AM PST

    Week in Ethereum News: lots of presents under the tree in this week's edition

    Posted: 23 Dec 2019 09:21 AM PST

    Ethereum on ARM. Raspberry Pi 4 "out of memory" crashes solution. ETH 2.0 on ARM progress (includes Prysm and Lighthouse clients for ARM64). Raspberry Pi 4 64bit support. New images available.

    Posted: 22 Dec 2019 11:31 PM PST

    Ethereum on ARM is a project that provides custom Linux images for Raspberry Pi 4 (Ethereum on ARM32 repo [1]), NanoPC-T4 [2] and RockPro64 [3] boards (Ethereum on ARM64 repo [4]) that run Geth or Parity Ethereum clients as a boot service and automatically turns these ARM devices into a full Ethereum node. The images include other components of the Ethereum ecosystem such as Status.im, Raiden, IPFS, Swarm and Vipnode as well as initial support for Eth2.0 clients.

    Images take care of all necessary steps, from setting up the environment and formatting the SSD disk to installing and running the Ethereum software as well as synchronizing the blockchain.

    All you need to do is flash the MicroSD card, plug an ethernet cable, connect the SSD disk and power on the device.

    Images update

    Note: If you are already running an Ethereum on ARM node (Raspberry Pi 4, NanoPC-T4 or RockPro64) you can update the Ethereum clients and ecosystem software by running the following command:

    sudo update-ethereum 

    Note 2: For solving the Raspberry Pi 4 memory issues, either flash the new Raspberry Pi 4 image below or follow the steps described on the "Raspberry Pi 4 RAM issues" section.

    DOWNLOAD LINKS

    For further info regarding installation and usage please visit Ethereum on ARM32 Github repo [1] and Ethereum on ARM64 Github [4]

    RASPBERRY PI 4 IMAGE

    NANOPC-T4 IMAGE

    ROCKPRO64 IMAGE

    ETHEREUM SOFTWARE INSTALLED

    • Geth: 1.9.9 (official binary)
    • Parity: 2.5.12 (cross compiled)
    • Swarm: 0.5.4 (official binary)
    • Raiden Network: 0.200.0~rc1 (official binary)
    • IPFS: 0.4.22 (official binary)
    • Status.im: 0.34.0~beta3 (cross compiled)
    • Vipnode: 2.3 (official binary)
    • Prysm: 0.2.7 (compiled. ARM64 only)
    • Lighthouse: 0.1.0 (compiled. ARM64 only)

    CHANGELOG

    • Raspberry Pi image
      • Enabled 64bit kernel for solving memory allocation issues
    • NanoPC-T4
      • Added support for official cooling set (fan and heatsink) [5]
      • Updated Ethereum software
      • Updated Prysm Eth2.0 client
      • Added Lighthouse Eth2.0 client
    • RockPro64
      • Updated Ethereum software
      • Updated Prysm Eth2.0 client
      • Added Lighthouse Eth2.0 client

    Raspberry Pi 4 RAM issues

    As reported recently on Github [6] there is a RAM allocation issue going on with the Raspberry Pi 4 that leaves the device completely unresponsive.

    While doing some research we found several issues on the Raspberry official forum related to this topic [7].

    It seems that the Raspbian Linux kernel has lots of problems handling 4GB of RAM (particularly on heavy i/o workloads). As so, The Raspberry Pi Foundation enabled a 64bit kernel on their official repository (note that the userland is still on 32bit). The 64bit kernel seems to fix the allocation memory issues.

    A new EthRaspbian image with the new 64bit kernel enabled by default is available (see above).

    If you are already running a Raspberry Pi 4 node, you can enable the 64bit kernel by following these steps:

    First, make sure you have the latest stable firmware installed:

    sudo rpi-eeprom-update 

    Enable the 64bit kernel and reboot:

    sudo echo arm_64bit=1 >> /boot/config.txt sudo reboot 

    Once logged in again, run:

    sudo uname -rm 

    You should get this output:

    4.19.75-v8+ aarch64 

    which means that you are now running the 64bit kernel.

    If for whatever reason you are running a higher kernel version (you installed the alpha/testing firmware with rpi-update tool), you can go back to the stable version by running:

    sudo apt-get update; sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel 

    RASPBERRY PI 4 FAST SYNC STATS WITH 64BIT KERNEL (4.19.75-v8+)

    • Date: 2019/12/19
    • Sync Time: 4 days and 3 hours
    • Blockchain size: 186 GB
    • Total State Entries downloaded: 419M

    We weren't able to reproduce the RAM issues running the 64bit kernel but this doesn't mean it is 100% fixed (more testing is needed). If you run into this or a similar memory problem please, report here or on Github (feedback appreciated).

    Ethereum 2.0 client progress

    As you may know, Eth 2.0 clients are progressing at a fast pace and the Beacon Chain release is around the corner. We are currently focusing our efforts on these Etherem 2.0 implementations (which already enabled public testnets):

    • Prysmatic Labs Prysm [8]
    • Sigma Prime Lighthouse [9]
    • Status Nimbus [10]

    As a first step, we are including the latest releases of Prysm and Lighthouse for the NanoPC-T4 and RockPro64 images (ARM64). As of today, nor Prysm neither Lighthouse compiles on ARM7 (Raspberry Pi 4). In the case of Prysm it will likely be solved in short [11]. Unfortunately, Lighthouse doesn't (and won't) support ARM7 at all [12].

    Raspbian will most probably migrate to 64bit in the near future so this will be no longer an issue once they complete this process.

    Again, if you are already running an Ethereum on ARM64 image (nanoPC-T4 or RockPro64) , you can install both clients by running:

    sudo apt-get update && sudo apt-get install prysm-beacon prysm-validator lighthouse 

    Regarding Prysm, as explained on an earlier post [13], follow the official instructions [14.1] (jump to "Get GöETH — Test ether" section) to join the public testnet. Basically, get the Goerli ETH (no real value), set the validator password and run both clients (beacon-chain and validator). Once you have done all required steps and make sure everything goes as expected you can edit the file /etc/ethereum/prysm-validator.conf and define the password previously set in order to run both clients as a systemd service:

    sudo systemctl start prysm-beacon sudo systemctl start prysm-validator 

    Lighthouse is provided as a single binary by now (so no config files or systemd service yet). Please, refer to their official documentation [15.1] (jump to "Start your Beacon Node" section) to test the software and join the public testnet.

    We are testing Status Nimbus as well and will try to include it soon.

    Expect a dedicated Ethereum on ARM image for testing Eth 2.0 clients on ARM devices (soonTM). Hopefully this will include an image for the Raspberry Pi 4 with Prysm and Nimbus clients.

    RASPBERRY PI 4 AND 64BIT

    Finally, some info regarding 64 bit support on Raspberry Pi 4. Although Raspberry Pi 4 CPU is 64bit capable, its official OS (Raspbian) is still based on 32bit [16]. Nowadays, it is hard to support 32bit software (as explained before, Prysm is running into issues compiling the client and Lighthouse doesn't even support it). Raspbian is going to migrate to 64bit but this will take some time.

    However, It is possible to run 64bit software on the Raspberry Pi 4. One option is to use a nspawn container (runs Raspbian with a 64bit kernel and 32bit userland combined with a 64bit systemd-nspawn userland container) [17.1].

    Other option is to install a native 64bit Linux image. As so, If you are eager to try the Eth 2.0 clients on the Raspberry Pi 4 (not tested and for advanced users only), you can follow these steps:

    1. Install the 64bit Ubuntu image for the Raspberry Pi [17.2]
    2. Add an ethereum user account and setup the storage in /home/ethereum (you can check this excellent guide by Grégoire Jeanmart to get an idea of how to do this [17.3]).
    3. Add the Ethereum on ARM64 repositories and install the Ethereum software:

    apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8A584409D327B0A5 add-apt-repository -n "deb http://apt.ethraspbian.com bionic main" add-apt-repository -n "deb http://apt.ethraspbian.com bionic-security main" add-apt-repository "deb http://apt.ethraspbian.com bionic-upgrades main" apt-get install geth parity swarm ipfs raiden status.im-node vipnode prysm-beacon prysm-validator 

    Again, this is not tested yet but it should work. Please, report here if you give it a try.

    References

    1. https://github.com/diglos/pi-gen
    2. https://www.friendlyarm.com/index.php?route=product/product&product_id=225
    3. https://store.pine64.org/?product=rockpro64-4gb-single-board-computer
    4. https://github.com/diglos/userpatches
    5. https://www.friendlyarm.com/index.php?route=product/product&product_id=263
    6. https://github.com/ethereum/go-ethereum/issues/20190
    7. Raspberry Pi Forum (memory issues)
      1. https://www.raspberrypi.org/forums/viewtopic.php?t=255433
      2. https://www.raspberrypi.org/forums/viewtopic.php?t=249924
      3. https://www.raspberrypi.org/forums/viewtopic.php?t=244367
      4. https://www.raspberrypi.org/forums/viewtopic.php?t=244849
      5. https://www.raspberrypi.org/forums/viewtopic.php?t=244531
    8. https://github.com/prysmaticlabs/prysm
    9. https://github.com/sigp/lighthouse
    10. https://github.com/status-im/nim-beacon-chain
    11. https://github.com/prysmaticlabs/prysm/issues/2546
    12. https://github.com/sigp/lighthouse/issues/706
    13. https://www.reddit.com/r/ethereum/comments/cgr9y4/ethereum_on_arm_nanopct4_and_raspberry_pi_images/
    14. Prysm documentation for joining the testnet, testnet info and block explorer
    15. https://prylabs.net/participate
    16. https://medium.com/prysmatic-labs/ethereum-2-0-development-update-41-prysmatic-labs-856851a1bd28
    17. https://beacon.etherscan.io
    18. Lighthouse documentation for joining the testnet and testnet updates
    19. https://lighthouse-book.sigmaprime.io/become-a-validator.html
    20. https://lighthouse.sigmaprime.io
    21. https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=252369&sid=2b6eb81b16071c28a9a616eabfaf4bc2
    22. Raspberry Pi 4 64bit. Raspbian container and 64bit distro images
    23. https://github.com/sakaki-/raspbian-nspawn-64
    24. https://ubuntu.com/download/raspberry-pi
    25. https://kauri.io/running-an-ethereum-full-node-on-a-raspberrypi-4-(model-b)/9695fcca217f46feb355245275835fc0/a/9695fcca217f46feb355245275835fc0/a)
    submitted by /u/diglos76
    [link] [comments]

    Full overview of Eth 2.0 & 1.x roadmaps from Messari

    Posted: 23 Dec 2019 09:37 AM PST

    Full section on Messari's Ethereum trends for 2020 here

    ETH 2.0 Research/Governance/Roadmap at a glance

    If history is any guide, we're not going to see ETH 2.0 until 2022 at the earliest, even if the earliest phases of "Serenity" begin getting pushed in mid-2020. ETH 2.0's rollout breaks down into seven (7!!!) phases and brings with it the promise of staking, sharding, a new virtual machine, and more dancing badgers.

    (One of our analysts, Wilson Withiam, put together an excellent overview of both the ETH 2.0 and ETH 1.x roadmaps for this report. They are critical to track and understand at a high-level given how much Ethereum's performance will affect other competitive projects and most of the DeFi and Web 3 infrastructure. So these next two sections are longer and more technical.)

    Here's what you need to know about the current game plan for crypto's largest platform.

    Phase 0 marks the launch of the "beacon chain", which will serve as the backbone for a new blockchain. The beacon chain will manage network validators (large early stakers like ConsenSys) and ultimately assign validators to individual shards (slicing the new blockchain into smaller chunks is a key, difficult, controversial scaling decision that's been made). The new chain will support Ethereum's new proof-of-stake consensus mechanism, and offer inflation rewards with new ETH2 for those that pony up and lock 32 ETH1 tokens into an irreversible contract. That one way bridge into the new system is also contentious, but it means ETH1 supply will start getting "effectively burned" once token holder begin claiming beacon chain validator slots. Initial reports claimed Jan. 3 as a realistic launch date (lol). It will be amazing to see this launched by end of June.

    Phase 1 will introduce 64 individual shard chains (reduced from 1,024!!!) to the network, with the option to increase the total down the road as the design gets tested. The Ethereum elite see sharding as the "key to future scalability" as shards can parallelize transaction processing, something that could improve network performance and reduce individual validator's costs (good for decentralization). It comes with big risk: this is still theoretical. No network the size of Ethereum has successfully sharded its blockchain. In Phase 1, shard chains will only contain simple data sets (no smart contracts or transaction executions) to test the system's structure. As with Phase 0, the beacon chain will continue to run in parallel with ETH 1.x throughout the phase. Don't expect Phase 1 anytime before 2021.

    Phase 2 marks the full launch of the ETH2 chain, allowing for on-chain contract execution and introducing the new eWASM virtual machine (dubbed EVM 2.0). At this point, existing dApps can start migrating their contracts from ETH 1.x to a specific shard (one shard per contract) in the new network. Storage rent, charging contract owners for storing data on the network (more on this below), is in the cards as well, which would require mass contract rewrites. Even though Phase 2 intends to replace the original Ethereum blockchain entirely, ETH 1.x may still live on as a shard within ETH2. (How confused are you by now? See why bitcoin will still dominate the macro narrative for a while?) A late 2021 release for Phase 2 is optimistic. Before the end of 2022 would be a win.

    The final four phases are less defined, and without an attached timeline:

    Phase 3 implements state-minimized clients (because stateless clients are just too much). Phase 4 allows for cross-shard transactions. Phase 5 improves network security and the availability of data proofs. Phase 6 introduces meta-shards, as in "shards within shards within shards," for near-infinite scaling. If you're scratching your head and are sadistic enough to read more, the Sharding Wiki page does note, "this may be difficult."

    Scaling and compilation efficiencies aside, the most notable change in Ethereum's metamorphosis is the transition from proof-of-work to proof-of-stake. PoW is the more battle tested security model for blockchain networks, while PoS may prove to be more efficient but with new and less obvious attack vectors. For the more technical, we recommend reading Bison Trails' Viktor Bunin on the subject of PoS security threats.

    Past research has also shown PoS requires an extra layer of "trust" vs. PoW, to help nodes sync to the network. Most models share specific characteristics to address this trust issue, such as allowing for a dynamic set of validators (rotate your security), promoting token holder participation in consensus, and assessing steep penalties (slashing) for any network participant that violates the protocol guidelines. ETH 2.0 will function similarly, but may be able to learn from other PoS networks (and their R&D) as well as those come live and see real world issues. As Vitalik points out, recent research in PoS resulted in "great theoretical progress," But...

    Listen, we're talking about practice. Not a game. Not a game. Not a game. We're talking about practice. Not a game….Practice? We're talking about practice, man? We're talking about practice. We're talking about practice. We ain't talking about the game. We're talking about practice, man.

    Vitalik was eight when this happened, so the clip might help and prove metaphoric.

    2 ETH 1.x Research/Governance/Roadmap at a glance.

    Ok, one more. Bear with us. Let's reiterate, ETH 2.0 is a brand new blockchain. It's going to be a chaotic and high-risk transition. In the meantime, the existing network needs to run existing applications (particularly financial settlements for DeFi transactions). More critical upgrades are needed in the current system.

    To that end, ETH 1.x devs have three goals to boost performance and reduce blockchain bloat: (1) introduce client optimizations that increase transaction capacity; (2) cap disk space requirements and prune old, memory-sucking data (so running a node is less expensive and more decentralized); and (3) upgrade the EVM to eWASM, a newer open standard for code compilers that simplifies debugging, and is also used by all the newer smart contract platforms.
    ETH 1.x developers have decided to split the major tasks amongst four working groups:

    • State Rent: Developers today incur a single payment for deploying contracts and storing data on the network. Thanks to the immutable nature of blockchains, this data occupies the disk space of node operators permanently. As the network's state grows, so do operating costs, which is where "state rent" comes in. It makes sense to charge for ongoing storage needs since the node operators are on the hook in perpetuity. This is a big change as it could break a bunch of contracts, but also limits state growth and creates economic incentives to run a node. What happens to data that users don't want to pay for? Boot delinquent user data off the network but keep a stub (a hash) of information on hand in case the user wants to later reinstate it.
    • Pruning: Similar goal. Pruning removes old data that is longer useful, but does so in a way that allows clients to prove past transactions. There are a couple of ways developers think this is possible (e.g. maintain a proof of deleted chain segments, which is similar to a "light client" in bitcoin that makes it possible to run a wallet on your phone), but all current strategies would cap annual "state growth" to prevent spikes in storage costs, at the expense of some new complications (e.g., dApps might be unable to access some data, and nodes might be unable to tell if data was deleted or whether it never existed in the first place).
    • eWASM: Like ETH 2.0, devs plan to implement eWASM on the flagship Ethereum chain. The eWASM virtual machine, a subset of the well-established WebAssembly compiler, offers improved flexibility for the introduction of "high-performance" smart contracts.
    • Simulation and Emulation: This group develops tools to help support and evaluate the other groups because, well, someone has to test everything.

    Core developers intend to introduce most of these implementations through a series of hard forks, the latest of which activated just over a week ago (Istanbul, Dec. 7). However, Istanbul's second phase, tentatively scheduled for Q2 next year, has Ethereans at each other's throats. The controversy boils down to the fork's inclusion of ProgPoW, an ASIC-resistant hashing algorithm designed to replace Ethereum's current algo. ProgPoW aims to even the playing field for GPU miners and ward off the entrance of potential ASIC competitors. The miners like that. But many miners and investors see ProgPoW as a threat to their investments. For miners, the change would shift the power dynamic away from mining farms and render expensive, specialized mining hardware useless. Ethereum (and ERC-20) investors intent on securing their assets might balk because ASIC miners typically prop up hash rates (overall chain security) and their costs "naturally create a price-floor for ASK prices of miners' sell-orders."

    This saga is far from over. The infighting will likely continue leading up to ProgPoW's activation date mid-next year, and presents the strongest potential for a network split since "The DAO" fork that spawned Ethereum Classic. The looming transition to ETH 2.0 (and proof-of-stake) will likely deter investor pushback, because it's a short-term battle in a war the miners are ultimately going to lose, anyway.

    Unless the roadmap changes back to supporting a hybrid PoW/PoS system, of course, but...
    Oh my god, I'm just kidding. This section is mercifully over.

    submitted by /u/CryptigoVespucci
    [link] [comments]

    Massive Mintbase VR NFT giveaway party was a hit (see the door jam)

    Posted: 23 Dec 2019 10:28 AM PST

    Release: Trinity v0.1.0-alpha.34 "Caroline Herschel" · ethereum/trinity · GitHub

    Posted: 23 Dec 2019 08:46 AM PST

    Proof-of-Stake is less wasteful -- Eric Wall

    Posted: 23 Dec 2019 08:09 PM PST

    [IMPORTANT] Muir Glacier Upgrade Announcement

    Posted: 22 Dec 2019 08:31 PM PST

    We all know DeFi was the biggest story of 2019. These are the most important developments that flew under the radar.

    Posted: 23 Dec 2019 08:27 AM PST

    Testnet Blockcain on disk size?

    Posted: 23 Dec 2019 04:32 PM PST

    Hi I want to create a node with full trace using Parity and the testnet (Ropsten?). Can you tell me what size SSD I must have on my VPS to fit the whole trace=on testnet blockchain? Thank you

    submitted by /u/ImStillRollin
    [link] [comments]

    Sent small amount of ETH to new address, it was swept. How can I prevent this in the future?

    Posted: 23 Dec 2019 10:23 AM PST

    I generated a new address the same way I've been doing it for years. I sent a super small amount of ETH to it to load it up for gas to be used for later. It was swept within a few minutes. That's never happened to me before. It was not my action that swept it either. I can see the address where the ETH was sent and this person has been sweeping small amounts of ETH to this address for some time now.

    Clearly someone else with a bot and they somehow had this private key. Has this happened to anyone else? Scary thing is, I generated the private key the same way I've been doing it for a long time.

    I've been reading about "weak private keys" and "ether combing". Is there a way to detect/prevent this?

    https://www.ise.io/casestudies/ethercombing/

    https://www.wired.com/story/blockchain-bandit-ethereum-weak-private-keys/

    submitted by /u/fasterthancocopuff
    [link] [comments]

    Ostrom's 8 principles of the commons set a baseline for community rules around shared resources. Can a 'cyber physical commons' be a technical & cultural template for communities to 'Automate Ostrom' and coordinate around shared goals? This is our take, what are your thoughts?

    Posted: 23 Dec 2019 04:49 AM PST

    Can anyone explain what these KICK tokens are that appeared in my ETH wallet and how to transfer them?

    Posted: 23 Dec 2019 03:01 AM PST

    They just appeared in my wallet. I saw kucoin had KICK listed so tried to send them there but got an error. Perhaps they are not actually the same token?

    Any ideas?

    submitted by /u/223am
    [link] [comments]

    The Diagrammer Series — Explaining The DEFI World In Diagrams

    Posted: 23 Dec 2019 02:33 AM PST

    No comments:

    Post a Comment