Naast cryptocurrency tokens stelt de blockchain analisten ook in staat om een duidelijker beeld te krijgen van praktisch elk GameFi project, NFT, marktplaats of DeFi protocol, dankzij Footprint.
Bij Footprint hebben we een methodologie gecreëerd die de ruwe blockchaingegevens compileert en zinvol samenvoegt. En dit geldt voor het programmeren van integraties.
1 . Manieren om met de blockchaingegevens te werken
Laten we het eerst hebben over manieren om integraties te programmeren. Er zijn een paar verschillende manieren om met blockchaingegevens te werken, en de door u gekozen aanpak zal afhangen van uw specifieke behoeften en doelen. Hier is een kort overzicht:
1.2 Eigen indexeringsoplossing
Het opzetten van een eigen indexer om met blockchaingegevens te werken kan verschillende voordelen en potentiële nadelen hebben. Hier volgen enkele voorbeelden van elk:
Voordelen:
- Aanpassing: Wanneer u uw indexer instelt, hebt u volledige controle over hoe de gegevens worden geïndexeerd en benaderd. Hierdoor kunt u de indexer aanpassen aan uw specifieke behoeften en voorkeuren.
Onafhankelijkheid: Door het opzetten van uw indexer bent u niet afhankelijk van een dienst van een derde partij om de index te onderhouden en bij te werken. Dit kan zorgen voor meer controle en flexibiliteit in uw werk met blockchaingegevens. - Verbeterde beveiliging: Wanneer u uw eigen indexer opzet, kunt u uw eigen beveiligingsmaatregelen implementeren om de gegevens te beschermen en ongeautoriseerde toegang te voorkomen.
Nadelen:
- Complexiteit: Het opzetten van uw indexer kan een complex en tijdrovend proces zijn, vooral als u nieuw bent in het werken met blockchaintechnologie. U moet de onderliggende technologie begrijpen en bereid zijn de tijd en moeite te investeren die nodig zijn om de indexer aan de praat te krijgen.
Onderhoud: Zodra u uw indexer hebt ingesteld, bent u verantwoordelijk voor het onderhouden en bijwerken ervan. Dit kan permanente technische kennis en middelen vereisen, wat een nadeel kan zijn als u niet over de nodige kennis of ondersteuning beschikt. - Kosten: Het opzetten van uw eigen indexer kan duur zijn, aangezien u de hardware en software moet kopen die nodig is om de indexer te laten werken en u de bijbehorende kosten, zoals elektriciteit en bandbreedte, moet betalen.
Over het geheel genomen kan het opzetten van uw eigen indexer om met blockchaingegevens te werken meer controle en maatwerk bieden, maar het kan ook een complex en duur proces zijn. Het is belangrijk om de voor- en nadelen zorgvuldig te overwegen voordat je beslist of dit de juiste aanpak is.
1.3 Database als dienst
Het gebruik van een indexer van derden om met blockchaingegevens te werken kan verschillende voordelen en potentiële nadelen hebben. Hier volgen enkele voorbeelden van elk:
Voordelen:
- Gebruiksgemak: Indexers van derden zijn doorgaans ontworpen om gemakkelijk te gebruiken te zijn, wat betekent dat u snel met de blockchaingegevens kunt beginnen te werken zonder dat u veel technische details hoeft te leren of uw aangepaste indexeringsoplossing moet uitvoeren (maakt niet uit of deze zelf ontwikkeld is of een kant-en-klare SDK).
- Geavanceerde zoekfunctionaliteit: Veel indexers van derden bieden geavanceerde zoekfunctionaliteit, zoals Booleaanse operatoren en reguliere expressies, waardoor het zoeken naar specifieke informatie op de blockchain gemakkelijker wordt. Deze kunnen vele feitelijke implementaties hebben, maar de geïndexeerde gegevens worden vaak toegevoegd aan een relationele database, wat volledige SQL-ondersteuning impliceert.
Schaalbaarheid: Indexers van derden zijn vaak ontworpen om grote hoeveelheden gegevens te verwerken, wat betekent dat ze een goede optie kunnen zijn als u gegevens van een grote blockchain moet doorzoeken of openen. - Betrouwbaarheid: Indexers van derden worden meestal gerund door professionele organisaties met de middelen en expertise om ervoor te zorgen dat de index altijd up-to-date en accuraat is. De oplossingen zijn niet altijd gedecentraliseerd, omdat ze gericht zijn op de verwerking van enorme hoeveelheden gegevens, maar de overgrote meerderheid is open source, wat het vertrouwen van de gebruiker in de dienst vergroot.
Nadelen:
- Afhankelijkheid: Als u een indexer van derden gebruikt, vertrouwt u op die dienst om de index te onderhouden en bij te werken. Als de indexer technische problemen ondervindt of offline gaat, hebt u mogelijk geen toegang tot de blockchaingegevens.
Beperkte aanpassing: Indexers van derden zijn meestal ontworpen om gemakkelijk te gebruiken te zijn, wat betekent dat ze misschien niet veel aanpassingsopties bieden. Dit kan het moeilijk maken om de indexer aan uw specifieke behoeften of voorkeuren aan te passen. - Kosten: Sommige indexers van derden vragen een vergoeding voor hun diensten, wat een nadeel kan zijn als u met een krap budget werkt.
Samengevat kan het gebruik van een indexer van derden om met blockchaingegevens te werken een handige en effectieve optie zijn, maar beperkt en soms ontbreekt het aan maatwerk.
1.4 Samenvatting
Het doel van Footprint is vooral om de lat voor het invoeren van analytics en het werken met web3-gegevens lager te leggen. Deze aanpak is een balans tussen gebruiksgemak en flexibiliteit. Daarom is een van onze diensten DaaS (Database as the service type). Voordat we de voordelen van onze dienst nader bekijken, kijken we ook naar een andere implementatiemogelijkheid voor de indexer, namelijk een zelfgeschreven oplossing of SDK.
In de volgende hoofdstukken zullen we de kernfunctie verkennen die read-only blockchain API’s zouden moeten hebben. We zullen het probleem vanuit verschillende invalshoeken bekijken en alternatieve oplossingen overwegen. Enkele van de belangrijkste kenmerken van blockchain-API’s zijn de volgende:
- Gebruiksgemak en flexibiliteit
- Schaalbaarheid
- Compatibiliteit
Gebruiksgemak en flexibiliteit zijn twee belangrijke kenmerken van blockchain-API’s. Een gebruiksvriendelijke blockchain-API zal het voor ontwikkelaars gemakkelijker maken om te beginnen met het bouwen van op blockchain gebaseerde toepassingen, zodat zij snel prototypes kunnen maken en hun ideeën kunnen testen zonder veel tijd te besteden aan het leren gebruiken van de API.
Flexibiliteit, aan de andere kant, verwijst naar het vermogen van een blockchain-API om een breed scala aan use cases en toepassingen te ondersteunen. Met een flexibele blockchain API kunnen ontwikkelaars toegang krijgen tot verschillende delen van de blockchain en toepassingen bouwen die interageren met verschillende soorten smart contracts en andere op blockchain gebaseerde activa. Dit kan vooral belangrijk zijn voor ontwikkelaars die toepassingen willen bouwen die in verschillende industrieën en contexten kunnen worden gebruikt.
In het algemeen kan het hebben van een blockchain-API die zowel gebruiksvriendelijk als flexibel is, het voor ontwikkelaars gemakkelijker maken om innovatieve en nuttige toepassingen te bouwen die kunnen profiteren van de unieke kenmerken en mogelijkheden van blockchaintechnologie.
1.5 Footprint Analytics
Gebruiksgemak en flexibiliteit worden gewaarborgd door onze gegevensorganisatie, die alle aspecten van interacties met het Footprint-ecosysteem beïnvloedt. Footprint heeft een API gebouwd bovenop dit datamodel waarmee gebruikers volwaardige datapijplijnen kunnen bouwen voor data-analyse en machine learning-toepassingen. We noemen het een Data API. We ondersteunen tegelijkertijd twee soorten API en twee subtypes binnen één daarvan om de meeste gevallen te dekken: Rest API en SQL API.
Met REST API kunnen we snel een toepassing integreren, aangezien elk eindpunt een vooraf gebouwd, hard-coded script is dat we als een van de populairste hebben geïdentificeerd. Alle eindpunten worden geleverd met gebruiksvriendelijke tools voor filteren, sorteren en pagineren.
Dankzij de meer aanpasbare interface van de SQL API kunt u dit verkrijgen voor meer specifieke gevallen. Een voordeel van het gebruik van dezelfde SQL-queries in zowel de webapplicatie als de API is dat het de ontwikkeling en het onderhoud kan vereenvoudigen. Door dezelfde queries in beide interfaces te gebruiken, hoeven ontwikkelaars geen aparte sets queries te schrijven en te onderhouden voor de webapplicatie en de API. Dit kan tijd en moeite besparen en het risico van fouten of inconsistenties tussen de twee interfaces verminderen.
Bovendien kan het gebruik van dezelfde SQL-query’s in zowel de webapplicatie als de API het voor ontwikkelaars gemakkelijker maken om een naadloze gebruikerservaring te creëren. Door dezelfde queries te gebruiken, kunnen ontwikkelaars ervoor zorgen dat de gegevens die door de webapplicatie en de API worden benaderd en gemanipuleerd, consistent zijn, zodat gebruikers tussen de twee interfaces kunnen schakelen zonder inconsistenties of storingen tegen te komen.
1.6 Andere platforms
Met veel alternatieve analyseoplossingen kan de gebruiker verschillende netwerken analyseren volgens verschillende niveaus van eisen. De meeste alternatieve oplossingen gaan echter tot het uiterste, met een zeer flexibel product dat kennis van querytalen of zelfs programmeertalen vereist, of een zeer eenvoudige interface met voorbereide scripts en dus weinig flexibiliteit.
Oplossingen zoals Moralis en Quicknode hebben alleen een REST API-interface. Ook al zijn er veel eindpunten, het beperkt de ontwikkelaar nog steeds in de flexibiliteit van de geretourneerde gegevens.
Dune heeft onlangs zijn API geïntroduceerd. Deze asynchrone oplossing impliceert het vooraf bestaan van een query op het platform onder een bepaald id (dune.com/query/{{query id}}), waarmee queries in de vorm van SQL kunnen worden uitgevoerd. De belangrijkste beperking van deze oplossing is de noodzaak om de SQL op het platform vooraf aan te passen, zodat de bijgewerkte query vervolgens wordt uitgevoerd.
Chainbase geeft op dezelfde manier als Footprint een SQL-API vrij. In tegenstelling tot Footprint beschikt Chainbase echter niet over een dergelijke geavanceerde ETL, zodat SQL-queries alleen voor ruwe transacties uitgevoerd kunnen worden.
2. Schaalbaarheid
Blockchain-API’s moeten grote hoeveelheden gegevens en transacties aankunnen, zodat ontwikkelaars toepassingen kunnen bouwen die door veel gebruikers tegelijk kunnen worden gebruikt.
2.1 Footprint Analytics
2.1.1 Moderne open data stack
Het Footprint-team heeft sinds de lancering in augustus 2021 verschillende architectonische upgrades doorgevoerd, dankzij het sterke vermogen om technologie te verkennen en te itereren. In minder dan anderhalf jaar tijd heeft het team deze veranderingen met succes kunnen doorvoeren. Dit is een bewijs van de vaardigheid en expertise van het team in technologie en data science.
Door te experimenteren heeft Footprint iteratief drie globale architectuurupdates doorgevoerd, om uiteindelijk te komen tot een architectuur die voldoet aan de eisen van de verschillende use cases van het platform. Meer informatie over de evolutie van de implementatie vindt u in het volgende artikel:
https://www.footprint.network/article/iceberg-spark-trino-a-modern-opensource-data-stack-for-blockchain-fp-HGZpPm3D
2.1.2 Sync en async uitvoeringen
Binnen Footprint zijn er twee modi voor het uitvoeren van queries naar de SQL API – synchroon en asynchroon. API-oproepen naar het synchrone eindpunt houden in dat de SQL-query door de Footprint-servers wordt uitgevoerd zodra een HTTP-verzoek van de toepassing wordt ontvangen, waardoor de verbinding in stand wordt gehouden. Dit is zinvol wanneer lichtgewicht verzoeken worden gebruikt, aangezien de toepassing in dit geval niet lang op de uitvoering hoeft te wachten. De details staan op de volgende pagina:
https://docs.footprint.network/reference/post_native
Voor zware verzoeken wordt aanbevolen een asynchroon verzoek te gebruiken. In tegenstelling tot een synchrone hoeft de clienttoepassing tijdens de uitvoering geen verbinding met de server te onderhouden. In plaats daarvan kan zij onmiddellijk het request-id krijgen, op basis waarvan zij na enige tijd afzonderlijk de uitvoeringsresultaten krijgt. Als onderdeel van de asynchrone API moeten twee stappen worden doorlopen om de gegevens op te halen – het volgende eindpunt wordt gebruikt om een “opdracht” voor SQL-uitvoering te verzenden:
https://docs.footprint.network/reference/post_native-async
De tweede stap is het verzenden van een verzoek om resultaten te ontvangen met de identifier die is verkregen bij de toegang tot het vorige eindpunt. Het eindpunt voor deze tweede stap wordt beschreven op de volgende pagina:
https://docs.footprint.network/reference/get_native-execution-id-results
2.2 Andere oplossingen
DuneV2 verandert de hele database-architectuur. Dune stapt nu over van een PostgreSQL database naar een Instance van [[Apache Spark]] gehost op [[Databricks]]. Alleen asynchrone API.
3. Compatibiliteit
Blockchain-API’s moeten compatibel zijn met een breed scala aan programmeertalen en ontwikkelomgevingen, zodat ontwikkelaars de tools en frameworks kunnen gebruiken waarmee ze het meest vertrouwd zijn.
REST is gemakkelijker te integreren omdat elke programmeertaal veel bibliotheken heeft die comfortabel werken met dit type API. Maar uiteindelijk werken zowel SQL API’s als REST over HTTP, dus de ontwikkelingservaring is vrijwel identiek wat betreft het standaard verzenden van een verzoek.
4. Samenvatting
Zoals we hebben geanalyseerd, volstaat het in de meeste gevallen voor een applicatie om gebruik te maken van kant-en-klare DaaS-oplossingen, omdat ze abstracties kunnen teruggeven (niet alleen ruwe gegevens) en veel tijd en geld besparen, omdat ze teams uiteindelijk in staat stellen zich niet op de infrastructuur maar op de waarde van het product te concentreren. Verschillende oplossingen in de DaaS-markt doorgenomen,
Footprint lijkt de meest optimale om te integreren, omdat het het meest flexibele model heeft voor het genereren van verzoeken en tegelijkertijd eenvoudig te gebruiken is en ook de moderne open-source data stack onder de motorkap heeft, die zorgt voor een ononderbroken en vooral snelle uitvoering van de meest complexe verzoeken.
