Ethereum Vitalik: Alternative proposal for early eth1 <-> eth2 merge |
- Vitalik: Alternative proposal for early eth1 <-> eth2 merge
- Week in Ethereum News: lots of presents under the tree in this week's edition
- 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.
- Full overview of Eth 2.0 & 1.x roadmaps from Messari
- Massive Mintbase VR NFT giveaway party was a hit (see the door jam)
- Release: Trinity v0.1.0-alpha.34 "Caroline Herschel" · ethereum/trinity · GitHub
- Proof-of-Stake is less wasteful -- Eric Wall
- [IMPORTANT] Muir Glacier Upgrade Announcement
- We all know DeFi was the biggest story of 2019. These are the most important developments that flew under the radar.
- Testnet Blockcain on disk size?
- Sent small amount of ETH to new address, it was swept. How can I prevent this in the future?
- 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?
- Can anyone explain what these KICK tokens are that appeared in my ETH wallet and how to transfer them?
- The Diagrammer Series — Explaining The DEFI World In Diagrams
| 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 | ||
| 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 updateNote: 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: 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
CHANGELOG
Raspberry Pi 4 RAM issuesAs 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: Enable the 64bit kernel and reboot: Once logged in again, run: You should get this output: 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: RASPBERRY PI 4 FAST SYNC STATS WITH 64BIT KERNEL (4.19.75-v8+)
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 progressAs 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):
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: 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: 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:
Again, this is not tested yet but it should work. Please, report here if you give it a try. References
[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 glanceIf 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.
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... [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
 | ||
| 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 [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/ [link] [comments]  | ||
| Posted: 23 Dec 2019 04:49 AM PST
 | ||
| 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? [link] [comments]  | ||
| The Diagrammer Series — Explaining The DEFI World In Diagrams Posted: 23 Dec 2019 02:33 AM PST
 |
![[IMPORTANT] Muir Glacier Upgrade Announcement](https://a.thumbs.redditmedia.com/8OVbBD7kXXZkB6Nd9O2OaVLnzOgqO8noUD1oLWmNgy8.jpg "[IMPORTANT] Muir Glacier Upgrade Announcement")
![[link]](https://i.redd.it/o9bgucuref641.png){kind=link}
| You are subscribed to email updates from Ethereum. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States | |
No comments:
Post a Comment