PIRL - Opgewaardeerd naar Lion Fork

Lion-fork-blog

Deel dit bericht

Delen op facebook
Delen op linkedin
Delen op twitter
Delen op email

Zoals jullie allemaal weten, is PIRL de eerste die op Ethash gebaseerde Masternodes heeft geïntroduceerd in het blockchain-ecosysteem en de eerste 51%-aanvalsbescherming heeft ontwikkeld voor op Ethash gebaseerde ketens die in verschillende projecten wordt gebruikt. Nu hebben ze enkele nieuwe updates doorgevoerd om hun privacy verder te verbeteren. Iedereen kan PIRL kopen met EUR / USD en BTC. Een gedecentraliseerde PIRL-chat is er voor communicatie en uw persoonlijke informatie is sterk beveiligd zonder zorgen over het lekken van privégegevens. Via de officiële mobiele PIRL-portemonnee kunnen gewillige kopers en verkopers gemakkelijk transacties uitvoeren.    

Een van de belangrijkste veranderingen is dat PIRL is opgewaardeerd naar "Lion Fork". Deze vork zal helpen om de moeilijkheid op te lossen wanneer blockchain uiteenvalt in twee paden naar voren, en Lion-vork zal aangeven welk pad moet worden gevolgd om de transactie op te slaan. Om een dergelijke begeleiding te doen hebben we de moeilijkheidsbom uitgeschakeld en de volgende vorken geactiveerd:

1. Constantinopelblok

2. Petersburg Block

3. Istanbul Block

In de 1.9.12-versie worden de volgende wijzigingen en oplossingen aangebracht om het efficiëntieniveau van het systeem te versnellen

· In de backend hebben we een nul (0x00 ... 0) -account ingesteld als standaard voor afzender eth_call als er geen was opgegeven (#20702).

· Een ontbrekende functie CallOpts. SetFrom is toegevoegd zodat een afzender de oproepinstellingen kan wijzigen (#20721).

· Interessant is dat Decouple-constanten in twee EIP's samen in Istanbul worden toegepast (#20646).

· Een console-regressie opgelost die de ondersteuning voor escape en unescape verloor (#20700). Escape () helpt bij het coderen van een tekenreeks om deze draagbaar te maken, zodat deze via elk netwerk kan worden verzonden naar elke computer die ASCII-tekens ondersteunt. Aan de andere kant wordt unescape () gebruikt om de gecodeerde string aan de ontvangerzijde te decoderen.

· Fixed a Failing Common Interface (CI) runs als gevolg van willekeur in TX fetcher scenario tests (#20712). We hebben dit probleem opgelost en de cases met succes getest.

· Een goroutine-lek in de propagatie van transacties verholpen (#20762). Een methode om dit probleem op te lossen om eventuele lopende verzoeken bij te houden en pas terug te keren van de buitenste methode wanneer de goroutine-verzoeken zijn voltooid.

· Een mogelijke datarace in de downloader verholpen (#20690). We hebben alle inconsistenties opgelost die eerder in de downloader zijn opgetreden.

In versie 1.9.11 zijn de volgende wijzigingen aangebracht om de werking van het systeem te versterken

·   Op DNS gebaseerde peer-detectie is nu ingeschakeld in Geth (#20592, #20660). Vanaf nu hebben Geth-knooppunten twee onafhankelijke mechanismen om peers te vinden. De DNS-lijsten dienen als uitwijkmechanisme wanneer peers niet kunnen worden gevonden via de DHT.

DNS-gebaseerde detectie is een gecentraliseerd mechanisme, maar we hebben geprobeerd de werking van dit mechanisme zo transparant en toestemmend mogelijk te maken. De openbare lijsten die standaard worden gebruikt, worden gegenereerd door de Discovery DHT te crawlen. Op dit moment zijn er ~ 1150 openbaar gerouteerde Ethereum mainnet-knooppunten in de standaardlijst. Onze openbare lijsten dienen ook voor de testnetwerken van Ropsten, Goerli en Rinkeby. Knooppunten met een Ethereum-client die implementeert EIP-868 en EIP-2124 verschijnen automatisch in de openbare lijsten.

U kunt het gebruik van op DNS gebaseerde detectie uitschakelen met de vlag-combinatie –discovery.dns “”.

Als u een DNS-gebaseerde knooppuntlijst voor uw privé- of openbare netwerk wilt maken, bekijk dan onze Installatiehandleiding voor DNS Discovery. We hopen dat andere organisaties dan de Ethereum Foundation in de toekomst openbare lijsten zullen aanbieden en deze lijsten graag in de standaardlijst zullen integreren met behulp van de 'link'-functie van EIP-1459.

· Transactieaankondigingen via eth / 65 (EIP 2464) is nu geïmplementeerd en Geth <-> Geth-verbindingen zouden aanzienlijk minder bandbreedte moeten gebruiken (#20234) voor het uitwisselen van transacties. De definitieve cijfers zijn echter een raadsel, omdat we moeten wachten op een wijdverbreide netwerkimplementatie. Deze functie is afhankelijk van de eth / 64 en eth / 65 protocolupdates, die nog niet worden ondersteund in alle Ethereum-clientimplementaties. Hoewel verbindingen tussen compatibele clients het nieuwe protocol zullen gebruiken, blijft geth compatibel met eth / 63 totdat de nieuwe protocolversies voldoende door het openbare netwerk zijn overgenomen.

· Er is overgeschakeld van de JavaScript-engine die ten grondslag ligt aan de Geth-console en de Clef-rule engine Otto naar Goja, wat het op ECMAScript 5.1+ -conformiteit zou moeten brengen. Natuurlijk niet uw nieuwste en beste.js-omgeving, maar aanzienlijk beter en sneller dan voorheen (#20470, #20599). 

Kleine functies en oplossingen

· Scheer een paar milliseconden van elk blok af via interne trie-optimalisaties (#20481, #20488De hash-bewerkingen worden gebruikt om te optimaliseren en de commit-bewerking wordt gebruikt om uitzonderingen af te handelen.

· Optimaliseer de uitvoering van EVM BLOCKHASH-opcode om het slechtste geval beter af te handelen (#20589).

· Controleer op beschikbaarheid van RPC API-naamruimte om typefouten in –rpcapi & co (#20597).

· Geth dump-genesis toevoegen om het volledige ontstaan en de kettingconfiguratie van een knooppunt af te drukken (#20191).

· In afwachting van bloknummerrapportage terugzetten tijdens ophalen van blok (#20616).

· Los een JavaScript-tracer-paniek op bij het openen van illegaal geheugen (#20612).

· Los een RPC-connectiviteitsprobleem op rond slechte verbindingen (#20414).

· C ++ hoofdnet en Geth Görli-opstartknooppunten opschonen (#20610). C ++ bootnode wordt langer gebruikt, dus we hebben Geth Görli ingebed.

· Fix bytes32 en bytes32 [] ondersteuning in Clef (#20609).

Het vonnis

Alle wijzigingen (wijzigingen en fixes) zijn aangebracht om de efficiëntie en uiteindelijk de veiligheid van het systeem te verhogen.

Abonneer op onze nieuwsbrief

Ontvang updates en leer van de beste

Meer te ontdekken

nl_NLNederlands
en_USEnglish fr_FRFrançais tr_TRTürkçe es_ESEspañol pt_PTPortuguês ru_RUРусский ko_KR한국어 zh_CN简体中文 hi_INहिन्दी nl_NLNederlands