Pirl 2.0 Seminar with substrate team ( Peoples behind Polkadot ) about the migration to nPOS and the future of Pirl
Watch the replay

PIRL – Upgraded to Lion Fork


Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

As you all know, PIRL is the first one who introduced Ethash based Masternodes to the blockchain ecosystem and developed the first 51% attack protection for Ethash based chains which is used in several projects. Now, they have successfully made some new updates to further enhance their level of privacy. Anyone can buy PIRL with EUR / USD and BTC. A decentralized PIRL chat is there for communication and your personal informations are highly secured with no worries about any leakage of private details. Through the official PIRL mobile wallet, willing buyers and sellers can make transactions easily.    

One of the major changes is that PIRL upgraded to “Lion Fork”. This fork will help to fix the difficulty when blockchain diverges into two paths forward, and Lion fork will guide which path to follow for saving the transaction. To do such guidance we have disable difficulty bomb and activated the following forks:

1. Constantinople Block

2. Petersburg Block

3. Istanbul Block

In the 1.9.12 version, following changes and fixes are made to speed up the efficiency level of the system

·  In the backend, we have set zero (0x00…0) account as a default for eth_call sender if none was specified (#20702).

·  A missing function CallOpts. SetFrom is added to allow a sender to change calls settings (#20721).

·  An interesting one is that Decouple constants in two EIPs are applied together in Istanbul (#20646).

·  Fixed a console regression that lost support for escape and unescape (#20700). Escape() helps to encode a string to make it portable, so it can be transmitted throughout any network to any computer that supports ASCII characters. On the other side, unescape() is used to decode the encoded string on the receiver side.

·  Fixed a Failing Common Interface (CI) runs due to randomness in TX fetcher scenario tests (#20712). We have fixed this failing and successfully tested the cases.

·  Fixed a goroutine leak in transaction propagation (#20762). One method to fix this issue to track any pending requests and only return from the outer method when the goroutine requests finish.

·  Fixed a possible data race in the downloader (#20690). We have fixed all the inconsistencies that arise previously in the downloader.

In version 1.9.11, following changes are made in order to strengthen system working

·   DNS-based peer discovery is now enabled in Geth (#20592, #20660). From now on Geth nodes have two independent mechanisms to find peers. The DNS lists serve as a fallback mechanism when peers cannot be found through the DHT.

DNS-based discovery is a centralized mechanism, but we have tried to make the operation of this mechanism as transparent and permission less as possible. The public lists used by default are generated by crawling the discovery DHT. At this time, there are ~1150 publicly routed Ethereum mainnet nodes in the default list. Our public lists also serve the Ropsten, Goerli and Rinkeby test networks. Nodes running any Ethereum client which implements EIP-868 and EIP-2124 will appear in the public lists automatically.

You can disable the use of DNS-based discovery using the –discovery.dns “” flag combination.

If you want to create a DNS-based node list for your private or public network, please check out our DNS Discovery Setup guide. We hope that organizations other than Ethereum Foundation will provide public lists in the future and will happily integrate those lists into the default one using the ‘link’ feature of EIP-1459.

·   Transaction announcements via eth/65 (EIP 2464) is now implemented and Geth<->Geth connections should use significantly less bandwidth (#20234) for exchanging transactions. Final numbers are anybody’s guess though, as we need to wait for widespread network deployment. This feature depends on the eth/64 and eth/65 protocol updates, which are not yet supported in all Ethereum client implementations. While connections between compatible clients will use the new protocol, geth will remain compatible with eth/63 until the new protocol versions are sufficiently adopted by the public network.

·   The JavaScript engine underlying the Geth console and Clef rule engine was switched from Otto to Goja, which should bring it up to ECMAScript 5.1+ compliance. Not your latest and greatest.js environment of course, but significantly better and faster than before (#20470, #20599). 

Minor features and fixes

·   Shave a few milliseconds off of each block via internal trie optimizations (#20481, #20488).The hash operations are used to optimize and commit operation is used to handle exceptions.

·   Optimize EVM BLOCKHASH opcode execution to handle the worst case better (#20589).

·   Check for RPC API namespace availability to detect typos in –rpcapi & co (#20597).

·   Add geth dump genesis to print the full genesis and chain configuration of a node (#20191).

·   Revert pending block number reporting during block retrieval (#20616).

·   Fix a JavaScript tracer panic when accessing illegal memory (#20612).

·   Fix an RPC connectivity issue around flaky connections (#20414).

·   Clean up C++ main net and Geth Görli boot nodes (#20610). C++ bootnode is longer in use, so we have embedded Geth Görli.

·   Fix bytes32 and bytes32 [] support in Clef (#20609).

The Verdict

All the amendments (changes and fixes) are made to increase the efficiency and ultimately the security of the system.

Subscribe To Our Newsletter

Get updates and learn from the best

More To Explore