tezblock Weekly Update #3
The weekly update for the current state and progress of the tezblock MVP development. Our goal is to include the community as much as possible along the way.
We’ve continued our work on development, testing and design in the last few days. If you’re interested what happened last week, you can take a look at the tezblock Weekly Update #2.
For this update we take a closer look at the summary of our evaluation process for the protocol indexer.
Tezos Protocol Indexer Requirements Engineering
With the focus on a release date of the MVP as soon as possible, we’ve decided early on in the requirements engineering process that we’ll evaluate existing protocol indexer solutions for the data instead of building something from scratch.
Keeping in mind that it should be possible at a later stage to switch out the whole indexer and use a different one from what we’ve selected initially for the MVP.
Summary — Evaluation Of Protocol Indexer
The following is the result of this process during which we have evaluated three existing Tezos protocol indexers.
A list of pros and cons for each indexer:
lib_indexer
- Pro — Is built by Nomadic Labs and is close to the client source code, therefore most likely kept up to date in the future
- Con — Currently still in draft phase, no actual implementation is available. Communication from the team that it will not be ready and Conseil should be considered
Conseil
- Pro — Increasing adoption in the community
- Pro — Extensive documentation regarding setup and usage.
- Pro — Very extensible queries, therefore support for many different use cases
- Neutral — Project funded through grant, development could be stopped or taken closed source
Kiln
- Pro — Increasing adoption in the community
- Con — Not all features that are required are available at the moment
- Neutral — Project funded through grant, development could be stopped or taken closed source
The Result
After reviewing all 3 projects, the decision was made to use Conseil because of the mature state of the project and the flexible API. Conseil supports all of the use cases tezblock will need in an MVP, but should also cover most use cases of later stages with minimal effort.
The tezblock architecture with all its components. The frontend is an Angular (Typescript) & Bootstrap application that uses the airgap-coin-lib to fetch data from a backend running Conseil.
Done, Ongoing And Upcoming Tasks
We’re currently focusing on the development of the frontend and continue with the user feedback rounds..
Usability & Design
- Continuation of the user tests, currently we’ve scheduled 6 more calls for this week. If you’re interested to provide feedback you can still complete the initial survey or reach out to us if you want to participate in a call.
- Improvements of the clickable prototype for the user tests.
Frontend
- Added transaction-list, block-list, transaction-detail, block-detail pages with data.
- Numerous styling & responsive improvements.
- Further improvements and getting almost all the data needed for the MVP.
Protocol indexer
A list of data Conseil does not provide that tezblock needs, plus possible APIs to use:
- Tezos Market Price & Historic Tezos Market Price (AirGap)
- Baker Names, Baking Fees, Payout Accurac (BakingBad)
- Baker Efficiency (MyTezosBaker)
The expected entities, this is subject to change during implementation:
interface LandingPageInfo {
currentCycle: number
currentCyclePercentage: number
nextCycleTimestamp: number
currentBlockHeight: number
cirulatingSupply: string
currentPrice: number
historicPrice: { timestamp: number; price: number }[]
}interface Account {
address: string
isRevealed: boolean
balance: string
price: number
originatedAccounts: Account[]
originatedAccountsCount: number
}interface DelegationInfo {
delegatedBalance: string
nextPayoutTimestamp: number
nextPayoutAmount: string
bakerName: string
bakerAddress: string
bakerFee: number
}interface BaseOperation {
hash: string
counter: number
gasLimit: number
storageLimit: number
source: string
fee: number
timestamp: number
blockLevel: number
blockHash: string
validOperation: boolean
}interface RevealOperation extends BaseOperation {
publicKey: string
}interface TransactionOperation extends BaseOperation {
destination: string
amount: string
parameters?: Buffer
internal?: Buffer
}interface DelegationOperation extends BaseOperation {
delegate?: string
}interface OriginationOperation extends BaseOperation {
balance: string
delegatable: boolean
managerPubkey: string
spendable: boolean
delegate?: string
script?: {
code: Buffer
storage: Buffer
}interface Endorsement {
hash: string
block: number
timestamp: number
endorser: string
slots: number[]
endorsedBlock: string
endorsedLevel: string
priority: number
}interface Vote {
hash: string
votingPeriod: number
kind: string // Enum?
proposalHash: string
rolls: number
ballot: string // Enum?
}interface BakerInfo extends Account {
bakerName: string
stakingBond: number
stakingBalance: number
stakingCapacity: number
currentDepositsBaking: number
currentDepositsEndorsement: number
pendingRewardsBaking: number
pendingRewardsEndorsement: number
bakingEfficiency: string
bakingEfficiencyLink: string
payoutAccuracy: string
payoutAccuracyLink: string
}
