Nu när nätverket har uppdaterats till version 11 och är stabil tänkte jag att det skulle vara en bra idé att lägga ut vad vi har på lager för nästa release och våra framtidsplaner. Vi kommer att påtrycka vårt större utvecklingsteam och arbeta på ett par projekt direkt för att möjliggöra några nya spännande funktioner på en gång.
Upprätthållande
Nätverksuppdelningen har rättats till på nätverket och vi har möjliggjort upprätthållande. De som inte har den korrekta noden efter idag kommer helt enkelt att avvisas av nätverket.
"InstantX"
För några månader sedan blev designen öppen källkod så att jag kunde arbeta med utvecklare för att förfina det. Hur som helst, det är för närvarande inte gjort och koden är en enkel prototyp från vad jag avsåg. Jag skulle rekommendera andra kryptovalutor att inte använda det tills vi har fått en chans att testa det grundligt och renodla logiken, annars kan stor skada göras på ditt nätverk.
Vi kommer att fullgöra utvecklingen av "InstantX" omedelbart efter arbetet med systemstabiliteten. Detta kommer att göras de kommande veckorna på testnet och kommer att vara en helt öppen och offentlig testfas.
"Masternode"-ändringar/-förbättringar
Som en uppgradering till "Masternode"-systemet kommer vi att flytta till ett pollettbaserat system där du endast kommer att behöva tillgång till din kalla plånbok någon gång varannan månad. När man startar en "Masternode" behöver man bara exekvera "masternode generate-token"-kommandot, vilket kommer att signera nyckeln och generera en pollettsträng att lägga in i "masternode.conf". Genom användandet av denna signatur kan flera "Masternodes"s startas flera gånger, även med protokollversionsuppdateringar.
Pingsystemet ("dseep) kommer att ersättas med ett "challenge request"-system vilken kommer att vara gjort på ett fullständigt decentraliserat sätt. Andra "Masternode"s på nätverket kommer att väljas vid varje block för att kontrollera deras användare genom att initiera "challenge request". Om en "Masternode" misslyckas med flera av dessa i rad genom att inte svara kommer den att tas bort från listan.
Då vi fortsätter in i framtiden kommer statiska "IPv4 IP":n fortlöpande bli en bristvara. I nästa release kommer vi att börja tillåta icke-statiska "IP":n att användas så länge klienten är kontakbar och kan svara på "challenge request".
Efter version 11.1 (kommer inte att vara i "InstantX"-relasen)
"Masternode"-förblindande
Nyligen kom en text ut av tre forskare på "Saarland University" som beskriver en ny teknik. Medan det finns allvarliga problem med hur de handskas med det. Konceptet med att förblinda användare de använder är nytt. I "CoinShuffle" är varje utdata skickat till nästa användare i en cirkel, en åt gången. Den nya användaren lägger till en utdata, blandar och skickar sedan listan igen. Vi kan göra detta och faktiskt förbättra det.
För att implementera förblindande kan varje användare ansluta till en helt slumpmässig "Masternode" och säga: "Skicka masternode X denna ut-/indata för att mixa och genomföra en enskild utdata". Den utdatan kommer att ges till den ledande "Masternode"n. Det kommer att behövas tillgång till alla använda "Masternode"s för att veta vem som gjorde vad, vilket är lika solitt som M rundor matematiskt (M=antal utdata). Detta är betydelsefullt eftersom alla användare kan överlämna all utdata på en gång. Så det är supersnabbt jämfört med "CoinShuffle" och till och med mycket säkrare.
Dencentralisering och "Masternode"-betalningssystem
För tillfället finns det en nod som signerar ett meddelande för varje block och säger vilken "Masternode" som ska betalas för det särskilda blocket. Som många användare vet var den centraliserade referensnoden en temporär lösning till problemet med att upprätthålla "Masternode"-betalningar. Gruvbrytare kan använda detta när man skapar ett block för att försäkra sig om att de går med på det. Om en gruvbrytare försöker lura systemet kommer blocket att avvisas av nätverket. Detta är en mycket bra temporär lösning men det är inte tillräckligt decentraliserat.
För att förklara den helt nya decentraliserade strategin måste vi först förklara exakt hur "Masternodes"-fungerar. När en "Masternode" startat skickar den ett meddelande vid namn "Masternode election entry". Detta lägger till "Masternode"n på en lista med alla nätverksklienter och tillåter dem att användas av alla nätverksklienter. Varje gång efter ett par minuter pingar "Masternode" nätverket genom att säga att de fortfarande lever och tillåter dem att tjäna räntebetalningar.
För att decentralisera systemet föreslår vi ett nytt system som vi kallar "Masternode mining". Detta betyder helt enkelt att när gruvbrytare får ett nytt "Masternode election entry" och löser ett block – bifogar "Masternode"n till blocket. Varje block kan innehålla 10 "Masternode" listförändringar. Genom att följa den vanliga framdriften av blockkedjan kan du sammanställa en lista med alla kända "Masternode"s. Detta system är också högresistent mot attacker och samma lista kan kompileras av vilken klient som helst på nätverket.
Till exempel:
Block 1: Lägg till mn1, mn2, mn3
Block 2: Lägg till mn4, mn5
Block 3: Ta bort mn2 //mn2 gick ur nätverket
-- för närvarande innehåller "Masternode"-listan : mn1, mn3, mn4, mn5
Block 4: Lägg till mn6, mn7
Block 5: Lägg till mn2 //mn2 kom tillbaka.
-- exempel på attack: --
Block 6: Ta bort mn1, mn2, mn3, mn4, mn5, mn6 //gruvbrytare äger "Masternode" 7, vill kontrollera nätverket.
Block 7: Lägg till mn1, mn2, mn3, mn4, mn5, mn6
I detta fall behövs en majoritet av gruvbrytningskraft för att kontrollera "Masternode"-listan. Om en gruvbrytare har tillräckligt med datorkraft att förändra "Masternode"-listan kommer de också ha tillräckligt med kraft att dubbelspendera en 51 %-attack. Därmed är detta den säkraste lösning för att decentralisera betalningen.
Upprätthållande
Nätverksuppdelningen har rättats till på nätverket och vi har möjliggjort upprätthållande. De som inte har den korrekta noden efter idag kommer helt enkelt att avvisas av nätverket.
"InstantX"
För några månader sedan blev designen öppen källkod så att jag kunde arbeta med utvecklare för att förfina det. Hur som helst, det är för närvarande inte gjort och koden är en enkel prototyp från vad jag avsåg. Jag skulle rekommendera andra kryptovalutor att inte använda det tills vi har fått en chans att testa det grundligt och renodla logiken, annars kan stor skada göras på ditt nätverk.
Vi kommer att fullgöra utvecklingen av "InstantX" omedelbart efter arbetet med systemstabiliteten. Detta kommer att göras de kommande veckorna på testnet och kommer att vara en helt öppen och offentlig testfas.
"Masternode"-ändringar/-förbättringar
Som en uppgradering till "Masternode"-systemet kommer vi att flytta till ett pollettbaserat system där du endast kommer att behöva tillgång till din kalla plånbok någon gång varannan månad. När man startar en "Masternode" behöver man bara exekvera "masternode generate-token"-kommandot, vilket kommer att signera nyckeln och generera en pollettsträng att lägga in i "masternode.conf". Genom användandet av denna signatur kan flera "Masternodes"s startas flera gånger, även med protokollversionsuppdateringar.
Pingsystemet ("dseep) kommer att ersättas med ett "challenge request"-system vilken kommer att vara gjort på ett fullständigt decentraliserat sätt. Andra "Masternode"s på nätverket kommer att väljas vid varje block för att kontrollera deras användare genom att initiera "challenge request". Om en "Masternode" misslyckas med flera av dessa i rad genom att inte svara kommer den att tas bort från listan.
Då vi fortsätter in i framtiden kommer statiska "IPv4 IP":n fortlöpande bli en bristvara. I nästa release kommer vi att börja tillåta icke-statiska "IP":n att användas så länge klienten är kontakbar och kan svara på "challenge request".
Efter version 11.1 (kommer inte att vara i "InstantX"-relasen)
"Masternode"-förblindande
Nyligen kom en text ut av tre forskare på "Saarland University" som beskriver en ny teknik. Medan det finns allvarliga problem med hur de handskas med det. Konceptet med att förblinda användare de använder är nytt. I "CoinShuffle" är varje utdata skickat till nästa användare i en cirkel, en åt gången. Den nya användaren lägger till en utdata, blandar och skickar sedan listan igen. Vi kan göra detta och faktiskt förbättra det.
För att implementera förblindande kan varje användare ansluta till en helt slumpmässig "Masternode" och säga: "Skicka masternode X denna ut-/indata för att mixa och genomföra en enskild utdata". Den utdatan kommer att ges till den ledande "Masternode"n. Det kommer att behövas tillgång till alla använda "Masternode"s för att veta vem som gjorde vad, vilket är lika solitt som M rundor matematiskt (M=antal utdata). Detta är betydelsefullt eftersom alla användare kan överlämna all utdata på en gång. Så det är supersnabbt jämfört med "CoinShuffle" och till och med mycket säkrare.
Dencentralisering och "Masternode"-betalningssystem
För tillfället finns det en nod som signerar ett meddelande för varje block och säger vilken "Masternode" som ska betalas för det särskilda blocket. Som många användare vet var den centraliserade referensnoden en temporär lösning till problemet med att upprätthålla "Masternode"-betalningar. Gruvbrytare kan använda detta när man skapar ett block för att försäkra sig om att de går med på det. Om en gruvbrytare försöker lura systemet kommer blocket att avvisas av nätverket. Detta är en mycket bra temporär lösning men det är inte tillräckligt decentraliserat.
För att förklara den helt nya decentraliserade strategin måste vi först förklara exakt hur "Masternodes"-fungerar. När en "Masternode" startat skickar den ett meddelande vid namn "Masternode election entry". Detta lägger till "Masternode"n på en lista med alla nätverksklienter och tillåter dem att användas av alla nätverksklienter. Varje gång efter ett par minuter pingar "Masternode" nätverket genom att säga att de fortfarande lever och tillåter dem att tjäna räntebetalningar.
För att decentralisera systemet föreslår vi ett nytt system som vi kallar "Masternode mining". Detta betyder helt enkelt att när gruvbrytare får ett nytt "Masternode election entry" och löser ett block – bifogar "Masternode"n till blocket. Varje block kan innehålla 10 "Masternode" listförändringar. Genom att följa den vanliga framdriften av blockkedjan kan du sammanställa en lista med alla kända "Masternode"s. Detta system är också högresistent mot attacker och samma lista kan kompileras av vilken klient som helst på nätverket.
Till exempel:
Block 1: Lägg till mn1, mn2, mn3
Block 2: Lägg till mn4, mn5
Block 3: Ta bort mn2 //mn2 gick ur nätverket
-- för närvarande innehåller "Masternode"-listan : mn1, mn3, mn4, mn5
Block 4: Lägg till mn6, mn7
Block 5: Lägg till mn2 //mn2 kom tillbaka.
-- exempel på attack: --
Block 6: Ta bort mn1, mn2, mn3, mn4, mn5, mn6 //gruvbrytare äger "Masternode" 7, vill kontrollera nätverket.
Block 7: Lägg till mn1, mn2, mn3, mn4, mn5, mn6
I detta fall behövs en majoritet av gruvbrytningskraft för att kontrollera "Masternode"-listan. Om en gruvbrytare har tillräckligt med datorkraft att förändra "Masternode"-listan kommer de också ha tillräckligt med kraft att dubbelspendera en 51 %-attack. Därmed är detta den säkraste lösning för att decentralisera betalningen.
Last edited by a moderator: