JAM is na 2.0, en is momenteel in een versnelde ontwikkelingsfase, met meer dan 30 teams die verschillende programmeertalen gebruiken en verschillende ontwikkelteams om een gedecentraliseerde JAM-client te realiseren (gebaseerd op het JAM-grijze boekprotocol). De vroegste ETH vereiste dat alle transacties door alle validators samen werden gevalideerd (dit deel kan eigenlijk worden bekeken in de Ethereum-gele boek, en er is een betere interpretatieversie). L2 laat een kleinere subset buiten de keten berekeningen uitvoeren, op twee manieren: de ene L2 is fraude bewijs (wanneer fraude wordt ontdekt, wordt de transactiecode opnieuw uitgevoerd om te verifiëren), de andere L2 is zk bewijs, wat geen herberekening vereist, maar een dure GPU nodig heeft om bewijs te genereren, de keten valideert alleen het bewijs zonder de eerdere transformatiecode van de transactie opnieuw uit te voeren. Vroeger gebruikte @Polkadot 1.0 een algoritme genaamd ELVES, dat niet zoals ETH's fraude-algoritme passief verifieert, maar een probabilistisch algoritme gebruikt voor actieve verificatie. Tijdens @polkadot 2.0 is de validatiegroep verpakt in een concept genaamd Core, dat in wezen een subset van de validatiegroep is. 2.0 ondersteunt Agile Coretime, wat betekent dat core dynamisch kan worden gebruikt; in 1.0 kon een keten slechts één Core gebruiken, maar na de lancering van 2.0 kan een keten coretime dynamisch gebruiken op basis van de vraag (aantal validatiesubsets), waardoor de servicebelasting van het systeem wordt verhoogd. JAM evolueert op basis van deze ideeën, met de opkomst van zoveel zk, op, slimme contracten, en zelfs gewone web2-achtige stateless applicaties. Kan het verder abstracte diensten creëren die goed passen bij deze verschillende applicatiemodellen en hen in staat stellen om samen te werken? Daarom heeft JAM een verdere abstractie op deze basis gedaan. - Verschillende soorten L2/parallele ketens worden nu aangeduid als diensten. - Blokken/transacties worden nu aangeduid als werkitems of werkpakketten. - Werkitems behoren tot diensten, terwijl werkpakketten een groep werkitems zijn. - Diensten worden beschreven door drie toegangspunten, waarvan er twee fn refine() en fn accumulated zijn. - De namen van deze twee toegangspunten zijn precies de reden waarom dit protocol JAM wordt genoemd: Join Accumulate Machine. Join verwijst naar fn refine(), alle Polkadot-kernen zullen parallel veel werk uitvoeren voor verschillende diensten. Join verwijst naar het verfijnen van gegevens tot een kleinere subset en deze doorgeven aan de volgende fase. - Accumuleren verwijst naar het accumuleren van de resultaten van alle bovenstaande operaties naar de hoofd-JAM-status. - Verschillende vormen van diensten worden ondersteund (op rollups, zkrollups, parallele ketens, stateless applicaties, slimme contracten). Het ETH-tijdperk is een gedeelde status van een enkele statusmachine, Het @polkadot 1.0 tijdperk is een interoperabele probabilistische shard-machine. Het @polkadot 2.0 tijdperk is een Agile Coretime-machine. Het JAM-tijdperk is de Join Accumulate Machine (JAM). Er zijn nog veel meer details en kenmerken, hier heb ik alleen de informatie gesynchroniseerd die ik begrijp. Wat voor nieuwe productmodellen kunnen er in de toekomst ontstaan door de combinatie van deze kenmerken met DEFI? Waarom kan JAM niet-status applicaties draaien, zoals JAM DOOM? Zie de video voor meer details: Leermateriaal: