This topic is to discuss the proposal submitted by @YashBit .Please see below for the details of the proposal and discussion.
6th Jan ,2025
Current status: Funded
Funding Note: Account updates are difficult to understand for developers working on Mina. This project is aimed at developers to improve their experience of building on Mina.
16th Oct ,2024
Current status: Under Consideration.
Opened for community discussion on 16th Oct, 2024.
The Mina Protocol enables complex transactions resulting in multiple account updates, including token transfers, state changes, and delegation modifications. Currently, developers can view these updates in JSON format using the toPretty() function. However, as transactions become more intricate, the JSON output becomes difficult to interpret, especially for transactions involving multiple accounts or complex smart contract interactions.
This project aims to develop a VSCode extension that integrates with JSON Crack to create a powerful transaction visualization tool that will:
By creating a more intuitive way to visualize and comprehend transaction structures directly within the development environment, this tool will significantly enhance the development experience on the Mina Protocol, addressing a key need identified by the developer community.
Complex transactions in the Mina Protocol result in JSON outputs that are difficult to interpret, especially for transactions involving multiple accounts or intricate smart contract interactions. This hinders developers’ ability to understand and debug their transactions efficiently within their development environment.
Develop a VSCode extension that integrates with JSON Crack to visually represent account updates and transaction structures. This tool will transform complex JSON outputs into intuitive, interactive graph visualizations directly within VSCode.
This proposal will significantly enhance the Mina ecosystem by:
The primary target audience includes:
The proposed VSCode extension for Mina Transaction Visualization will integrate with JSON Crack and focus on the following components:
State Analyzer:
JSON Crack Integration:
VSCode Extension Interface:
Diagram 1: High Level Design of Information Flow
Diagram 2: Example UI
Our vision for this project is to create a seamless, in-editor transaction visualization tool that significantly improves the Mina development experience. Key aspects of this vision include:
By realizing this vision, we aim to improve the developer experience and contribute to the growth of the Mina ecosystem. This VSCode extension will serve as a powerful tool in the Mina development toolkit.
State Analyzer:
VSCode Extension (Basic Version):
JSON Crack Integration (Partial):
Week 1-2:
Week 3-4:
Week 5-6:
Final 2 weeks:
Development Costs: 35,000 MINA
Testing and Quality Assurance: 5,000 MINA
Documentation and Deployment: 3,000 MINA
Project Management: 2,000 MINA
B62qrF8xMKPPQMCwK2J7Ey47CGy1bKvaKhYNuYURN8qVohr1NJcnhRj
Proposer Github: If you have Github profiles that are relevant to this proposal, list them here.
Yash Bharti: YashBit (yash_b) · GitHub
Proposer Experience: If you have relevant experience building zkApps or other dApps, provide that information here. If available, include links.
Team Members:
Technical Complexity: Enhanced parsing of AccountUpdate objects may be more complex than anticipated.
Mitigation: Begin with thorough analysis of existing code. Prioritize core functionalities and prototype early.
Performance Issues: Increased detail in visualization may cause performance bottlenecks.
Mitigation: Implement progressive rendering and lazy loading. Conduct regular performance testing.
Compatibility with Future Mina Updates: Changes to Mina’s transaction structure could break the visualizer.
Mitigation: Design a modular core engine. Maintain communication with Mina core team. Implement extensive unit testing.
Scope Creep: Risk of exceeding the 1.5-month timeline due to feature expansion.
Mitigation: Clearly define and prioritize features upfront. Use agile methodologies. Be prepared to adjust scope to meet timeline.
By anticipating these risks and implementing mitigations, we aim to ensure smooth development and delivery of the Enhanced Mina Transaction Visualizer within the proposed timeline and budget.
I find this proposal quite interesting.
It has two main benefits from my perspective:
The proposal itself: It should make debugging zkApps much easier by allowing easy identification of state changes. It would be great if events, actions, and possibly some chain information like block height were also displayed.
Potential team acquisition: With this proposal implemented, Mina can acquire a team that understands both Mina’s architecture and the structure of VS Code. This team would be able to create additional modules for VS Code, with potential plugins such as unprovable code detection, debugging tools, and more.
The only concern is the team’s experience in development using o1js. If they lack this experience, a mentor with expertise would be necessary, as Mina has some unique features that can take time to master, potentially affecting the proposal’s timeline.
I am summarising the feedback we have received from developers in the community.
The AccountUpdates has different representations depending on where and how we view them
tx object (not JSON) after Mina.transaction is a tree, and there is NO function that serialize it fully. This function should be developed, probably as o1js PR in case there will be private fields not accessible or, other way, access the fields by using any, bypassing o1js controls.
It is important to get errors when sending the tx and link the errors to the specific AccountUpdates.All of the above representations except first are flat arrays, the first is tree with child updates and is more interesting to analyze.It is not enough to visualize the JSON produced by o1js by default.
It would be great to support several standard contracts to mark the type of contracts and accounts in AccountUpdates (like FungibleToken and FungibleTokenAdmin) in visualizations.
State Analyzer:
Code Parser: Extracts account states from the code in VSCode
State Transition Detector: Identifies changes between states
Relationship Builder: Creates relationships between state variables
AccountUpdate building is deep in the o1js code and you wont be able to rebuild AccountUpdates just by analyzing the contract code, you need actually run Mina.transaction to get the forest of AccountUpdates.
It would be better if the team spends some time working with account udpdates to understand the current issue and update the proposal as the solution aimed for VS code might not be feasible. It might be easier to start with balance transfer states & move to zkApp states. We feel the solution improving the JSON output of the update is more helpful than a VS code integration.
After discussing with the team, this proposal is on hold and the team will be researching designs on the solution in the coming weeks.
Below is the revised proposal based on the feedback.
The Mina Protocol enables complex transactions resulting in multiple account updates, including token transfers, state changes, and delegation modifications. Currently, developers can view these updates in JSON format using the toPretty() function. However, as transactions become more intricate, the JSON output becomes difficult to interpret, especially for transactions involving multiple accounts or complex smart contract interactions.
This project aims to create a NPM Package to recursively traverse the transaction tree and take a snapshot to create a powerful visualization of the state transformations. The tool will aim to:
By creating a more intuitive way to visualize and comprehend transaction structures directly within the development environment, this tool will significantly enhance the development experience on the Mina Protocol, addressing a key need identified by the developer community.
Complex transactions in the Mina Protocol result in txn and account update trees that are difficult to interpret, especially for transactions involving multiple accounts or intricate smart contract interactions. This hinders developers’ ability to understand and debug their transactions efficiently within the development environment.
Develop a NPM Package that can be invoked on txn and accounts update (AU) tree to recursively traverse it and decipher the salient data in the nodes and leafs. Also, create a visualisation of the state transitions and call out the associated updates to the tree.
This proposal will significantly enhance the Mina ecosystem by:
The primary target audience includes:
Listed below are the components of the Mina Txn Visualiser
State Analyser:
Visualiser:
Below is a high level class diagram of the state analyser and visualiser. (This may go through changes during the actual implementation)
Our vision for this project is to create a seamless, transaction visualization tool that significantly improves the Mina development experience. Key aspects of this vision include:
By realizing this vision, we aim to improve the developer experience and contribute to the growth of the Mina ecosystem. This package will serve as a powerful tool in the Mina development toolkit.
State Analyzer:
Visualiser:
Deliver code to
# Token Escrow Account Update Forest
## Account Types & Addresses
### Test Accounts
- **Deployer** (Local Account 0)
- Role: Deploys contracts and funds initial accounts
- Type: Local blockchain test account
- **Owner** (Local Account 1)
- Role: Token admin operations and escrow control
- Type: Local blockchain test account
- **Alexa** (Local Account 2)
- Role: Token holder and escrow depositor
- Type: Local blockchain test account
- **Billy** (Local Account 3)
- Role: Token holder and escrow depositor
- Type: Local blockchain test account
- **Jackie** (Local Account 4)
- Role: Token recipient
- Type: Local blockchain test account
### Contract Accounts
- **Token Contract** (`PrivateKey.randomKeypair()`)
- Type: FungibleToken
- Features:
- Symbol: "abc"
- Decimals: 9
- Start State: Unpaused
- **Escrow Contract** (`PrivateKey.randomKeypair()`)
- Type: TokenEscrow
- Features:
- Owner: Local Account 1
- Token Address: Token Contract's public key
- **Admin Contract** (`PrivateKey.randomKeypair()`)
- Type: FungibleTokenAdmin
- Features:
- Admin: Admin's public key
## Transaction Flow
### 1. Initial Setup & Deployment
Deployer → AdminContract
│ └─ Action: Fund (3 accounts)
│ └─ Fee: 1e8
│
Deployer → TokenContract
│ └─ Action: Deploy
│ └─ TokenId: {derived from token address}
│
Admin → TokenContract
└─ Action: Initialize
└─ Parameters:
- symbol: "abc"
- decimals: 9
- startPaused: false
### 2. Escrow Setup
Deployer → EscrowContract
│ └─ Action: Fund & Deploy
│ └─ Fee: 1e8
│
EscrowContract → TokenContract
└─ Action: Approve Account Update
### 3. Token Distribution
Owner → Alexa
│ └─ Action: Mint 2e9 tokens
│ └─ Fee: 1e8
│
Owner → Billy
└─ Action: Mint 3e9 tokens
└─ Fee: 1e8
### 4. Escrow Operations
Alexa → EscrowContract
│ └─ Action: Deposit 2e9 tokens
│ └─ Fee: 1e8
│
Billy → EscrowContract
│ └─ Action: Deposit 3e9 tokens
│ └─ Fee: 1e8
│
Owner → EscrowContract
│ └─ Action: Withdraw 4e9 tokens
│ └─ Fee: 1e8
│
EscrowContract → Jackie
└─ Action: Transfer 4e9 tokens
### 5. Failed Operation
Jackie ╳ EscrowContract
└─ Action: Direct withdraw attempt (1e9 tokens)
└─ Status: REJECTED
└─ Fee: 1e8
## Balance States
### Initial Token Distribution
- Alexa: 2e9 tokens
- Billy: 3e9 tokens
- Escrow: 0 tokens
- Jackie: 0 tokens
### After Deposits
- Alexa: 0 tokens (all deposited)
- Billy: 0 tokens (all deposited)
- Escrow: 5e9 tokens
- Jackie: 0 tokens
### After Withdrawal
- Alexa: 0 tokens
- Billy: 0 tokens
- Escrow: 1e9 tokens
- Jackie: 4e9 tokens
Below are code snippets indicating how the analyser and the visualiser could get invoked.
const tracker = new AccountUpdateTrace();
const visualizer = new ASCIITreeVisualizer();
const deployTxnSnap = tracker.takeSnapshot(deployTxnAU, 'deploy')
console.log(visualizer.visualizeChangeSummary(tracker.getSnapshots()));
Week 1-2:
Week 3-4:
Week 5-6:
Final 2 weeks:
Development Costs: 22,500 MINA
Testing and Quality Assurance: 5,000 MINA
Documentation: 3,000 MINA
Project Management: 2,000 MINA
B62qrF8xMKPPQMCwK2J7Ey47CGy1bKvaKhYNuYURN8qVohr1NJcnhRj
Proposer Github:
Yash Bharti: YashBit (yash_b) · GitHub
Proposer Experience: If you have relevant experience building zkApps or other dApps, provide that information here. If available, include links.
Team Members:
Technical Complexity: Enhanced traversal and parsing of AccountUpdate forest may be more complex than anticipated.
Mitigation: Begin with thorough analysis of existing code. Prioritize core functionalities and prototype early.
Performance Issues: Increased detail in visualization may cause performance bottlenecks.
Mitigation: Implement progressive rendering and lazy loading. Conduct regular performance testing.
Compatibility with Future Mina Updates: Changes to Mina’s transaction structure could break the visualizer.
Mitigation: Design a modular core engine. Maintain communication with Mina core team. Implement extensive unit testing.
Scope Creep: Risk of exceeding the 2-month timeline due to feature expansion.
Mitigation: Clearly define and prioritize features upfront. Use agile methodologies. Be prepared to adjust scope to meet timeline.
By anticipating these risks and implementing mitigations, we aim to ensure smooth development and delivery of the Enhanced Mina Transaction Visualizer within the proposed timeline and budget.
This proposal is funded.Account updates are difficult to understand for developers working on Mina. This project is aimed at developers to improve their experience of building on Mina