中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC044
Solana’s account-access model helps a runtime identify transactions whose execution need not compete over the same writable state. The important question is not whether two transactions call different programs. It is whether their effective account accesses conflict, and whether the chosen execution preserves the required state relationships.
Two transactions may share read-only accounts without a read/write conflict. If either transaction writes an account the other reads or writes, our classroom model must keep their executions apart. A shared writable fee payer can create such a conflict even when their application records differ.
This lesson builds a complete six-transaction schedule, checks its resulting state and then changes one hidden assumption. The aim is to understand where parallelism comes from and what an impressive-looking schedule does not prove.
Choose your reading route
In this guide
- 1. Why account access belongs in the architecture
- 2. Read-only, writable and signer are different labels
- 3. The conflict test
- 4. Set up the six transaction cards
- 5. Derive the six conflict edges
- 6. Preserve the chosen conflicting order
- 7. Check the resulting state
- 8. A different serial order can mean a different result
- 9. The shared fee-payer variation
- 10. Declaring too much or too little
- 11. Execution eligibility is not complete transaction validity
- 12. What three waves do and do not measure
- 13. Exercise: repair the proposed schedules
- 14. A compact review checklist
- 15. Frequently asked questions
- Sources and next reading
Begin with read-only and writable access. Follow the six transaction cards, draw their conflict edges, and check the three-wave schedule. Then test the shared-payer variation and the exercise answers.
All account names, program actions and time units are fictional. No real accounts, transactions, signatures, payments or deployment are created. The worksheet is an explicit scheduling model, not a reproduction of a production validator’s entire scheduler.
Sources were checked on 12 October 2026. The implementation reference is pinned to Agave v3.0.0. Current documentation is used only for the narrow account, instruction and processing concepts stated; no throughput ranking or active-upgrade claim follows from it.
Back to contents · Next section
1. Why account access belongs in the architecture
A Solana instruction identifies a program and the accounts it uses. The transaction gathers the instructions and the relevant account information. This gives the runtime information about shared-state access before those program operations finish executing.
The Solana instructions documentation describes the program identifier, account list and instruction data. The transaction structure documentation distinguishes signer and read-only information in the described message format.
For this lesson, use effective, resolved access sets: all relevant account addresses have already been identified, and their actual read-only or writable classification for the scheduling model is supplied. We do not try to decode a transaction format or resolve an address lookup table by hand.
This distinction prevents a subtle shortcut. An instruction’s small application list may not be the whole transaction’s access set. Fee payment and other instructions can introduce shared writable accounts that disappear from an oversimplified application diagram.
Back to contents · Next section
2. Read-only, writable and signer are different labels
A read-only classification permits the relevant access without treating that account as writable for the transaction. Writable access requires exclusive treatment against other reads and writes in our model. It is an account-level classification, not a promise that a particular instruction will definitely change every byte.
Signer information answers an authorisation question. Writable information answers an access question. An account need not be a signer merely because an authorised program changes its data, and a signing authority need not have its own account data modified by the application action.
Neither label replaces the program’s checks. Marking an account writable does not grant arbitrary permission to alter somebody else’s data or bypass the account ownership and runtime rules. The model assumes those validity and authorisation requirements are separately satisfied.
For clarity, let R(T) mean T’s effective read-only set and W(T) its effective writable set. Any reads of a writable account are covered by W(T); do not list that account in R(T) as though the transaction were merely a reader.
Back to contents · Next section
3. The conflict test
Two transactions conflict in the classroom model when a writable account of either appears in the other’s read-only or writable set. Shared read-only accounts alone do not create a conflict.
Equivalently, check three intersections: W(A) with W(B), W(A) with R(B), and R(A) with W(B). If any is nonempty, A and B cannot occupy the same execution wave here. If all are empty, account access permits the pairing under the supplied assumptions.
The pinned Agave v3.0.0 account handling source includes read/write locking logic and tests that distinguish shared readers from conflicting writes. Its batch handling has implementation-specific options; our waves are a teaching model, not a claim that every transaction sharing a batch is rejected or run in exactly this pattern.
A conflict edge says that access needs coordination. It does not say which transaction has higher priority, which should be included, or that either is invalid. Those are additional decisions.
Back to contents · Next section
4. Set up the six transaction cards
Our fictional programme P manages five ordinary integer data accounts: C, X, Y, Z and W. Initially C=2, X=10, Y=20, Z=0 and W=0. The values are classroom counters, not token balances or physical measurements.
Every transaction reads the same unchanged program account P. Each has its own distinct writable fee-payer account f1 through f6. These payer accounts are different from all application accounts and from each other; they have adequate resources, and their fee effects do not alter the five counters.
All other required accesses are supplied as either shared read-only accesses or unique nonconflicting accesses. There are no hidden shared writable accounts, cross-program calls, upgrades or other transactions in the example. Every listed action succeeds under its specified state conditions.
- T1: R={C,P}; W={X,f1}. Add the current C to X.
- T2: R={C,P}; W={Y,f2}. Add the current C to Y.
- T3: R={X,P}; W={Z,f3}. Copy the current X into Z.
- T4: R={P}; W={C,f4}. Set C to 3.
- T5: R={P}; W={X,f5}. Double the current X.
- T6: R={Y,P}; W={W,f6}. Copy the current Y into W.
The reference serial order is T1, T2, T3, T4, T5, T6. We seek a schedule that preserves this order for conflicting pairs, while allowing nonconflicting work to share a wave.
Back to contents · Next section
5. Derive the six conflict edges
T1 conflicts with T3 because T1 writes X and T3 reads X. It conflicts with T5 because both write X. It also conflicts with T4: T1 reads C while T4 writes C.
T2 conflicts with T4 through C, and with T6 through Y. T3 conflicts with T5 through X. Those are all six unordered conflict pairs: T1–T3, T1–T4, T1–T5, T2–T4, T2–T6 and T3–T5.
T1 and T2 both read C and P, but write different application accounts and use different payers. They therefore have no conflict edge. T3 and T6 likewise read different data and write different destinations, while sharing only the read-only P.
This is a useful place to check completeness. Six transactions create fifteen unordered pairs. A careful answer classifies all fifteen, not merely the first few obvious clashes. The nine remaining pairs are compatible under the supplied access assumptions.
Back to contents · Next section
6. Preserve the chosen conflicting order
The reference order turns each conflict edge into a direction. T1 must precede T3, T4 and T5; T2 must precede T4 and T6; T3 must precede T5. No additional order is imposed between a pair solely because its labels have different numbers.
One permitted schedule is:
- Wave 1: T1 and T2.
- Wave 2: T3, T4 and T6.
- Wave 3: T5.
Each wave contains only compatible transactions, and every directed conflict runs from an earlier wave to a later one. T6 can move before T5 because they do not conflict. T4 can share a wave with T3 even though T4 writes C: T3 reads X, not C.
These are both necessary checks for this worksheet. Testing only the contents of each wave could accidentally reverse a required dependency across waves. Testing only order could overlook two conflicting operations placed together.
Back to contents · Next section
7. Check the resulting state
Wave 1 begins with C=2. T1 changes X from 10 to 12; T2 changes Y from 20 to 22. C remains 2, and Z and W remain zero. Neither transaction needs a result produced by the other.
Wave 2 begins after both wave-1 transactions finish. T3 copies X=12 into Z. T4 sets C=3. T6 copies Y=22 into W. These operations touch the supplied accounts compatibly, giving C=3, X=12, Y=22, Z=12 and W=22.
Wave 3 doubles X from 12 to 24. The final application state is C=3, X=24, Y=22, Z=12 and W=22. Fee-payer balances are outside this counter calculation, but their writable access was included in the conflict analysis.
Now replay the reference serial order. T3 still copies 12 before T5 doubles X; T1 and T2 still read C before T4 changes it. The same final counter values follow. The schedule preserved the relevant dependencies, not merely a pleasing arrangement of boxes.
Back to contents · Next section
8. A different serial order can mean a different result
Suppose someone moves T4 ahead of T1 and T2. C becomes 3 before their reads, so T1 produces X=13 and T2 produces Y=23. If T3 then copies X and T5 later doubles it, the final state becomes C=3, X=26, Y=23, Z=13 and W=23.
That may be the result of a different serial ordering, but it is not the result required by our chosen reference order. A scheduler cannot justify this change by saying all operations are individually well formed.
Similarly, placing T5 before T3 changes what T3 observes: after T1 and then T5, X is 24, so T3 would store Z=24 rather than 12. Correctness depends on the intended ordering of conflicting access.
The example separates two questions: can operations overlap safely under the given access model, and which ordering is being preserved? Solving the first question does not give permission to choose an arbitrary answer to the second.
Back to contents · Next section
9. The shared fee-payer variation
Replace f1 through f6 with the same writable payer S for every transaction. Leave all application operations unchanged. Now each pair shares S in its writable set, so every pair conflicts under this worksheet’s model.
With one transaction per conflict-free wave, the six transactions require six waves rather than three. The application records still look separate in several cases, but the complete access sets reveal their shared dependency.
This is a conceptual diagnosis, not advice to create or fund more accounts. A real design also has authorisation, operational and resource constraints. Nor does it imply a universal throughput number for sponsored transactions: production scheduling and implementation details still matter.
The practical reading habit is to ask for the whole effective account set before accepting a parallelism claim. “Different users” or “different catalogue entries” does not prove independence when another writable resource is shared.
Back to contents · Next section
10. Declaring too much or too little
Suppose T1 actually only reads C, but its effective classification unnecessarily makes C writable. It would then conflict with T2’s read of C. The original first wave would no longer pass the model’s test, even if this particular program path never changed C.
An access declaration describes what the runtime must allow and coordinate, not only the writes a reader expects from one successful example. Excess writable classification can therefore reduce the set of available parallel pairings.
The opposite shortcut is worse: an operation cannot legitimately change X while pretending it has only read-only access to X. A claim of extra parallelism obtained by omitting required access has not solved the state-conflict problem.
Likewise, two fields stored inside the same writable account do not automatically become independently lockable resources in an account-level model. A different state layout may change dependencies, but it also changes the design and must preserve the application’s invariants.
Back to contents · Next section
11. Execution eligibility is not complete transaction validity
Our six cards assumed valid signatures, authorisation, sufficient resources and successful program conditions. Removing those assumptions would introduce other reasons a transaction could fail, even if its accounts do not conflict with its neighbours.
The Solana transaction pipeline documentation describes checks and processing beyond scheduling, including signature verification, structural checks, account loading and instruction execution. Its fee and failure handling also warns against treating every unsuccessful attempt as if nothing at all could change.
This lesson does not implement those stages or their full accounting. It uses their existence to limit the conclusion: compatibility of account sets is one scheduling property, not a certificate of authorisation, successful execution, inclusion or finality.
For the same reason, concurrent execution on a node is not a complete description of network consensus. An account-conflict worksheet does not establish how every network participant agrees on history, and it should not be marketed as doing so.
Back to contents · Next section
12. What three waves do and do not measure
If every transaction took one invented unit of execution time, unlimited resources existed within a wave and coordination had zero cost, our three-wave schedule would take three units. The six-step reference serial schedule would take six units under those same toy assumptions.
That is a model comparison, not a measured twofold production speedup. Real transactions have different costs. Available cores, memory access, account loading, scheduling overhead and other limits can prevent all compatible operations from running together.
Our dependency chain T1 before T3 before T5 already requires at least three ordered execution positions in this model. The exhibited schedule meets that lower bound, so three waves are optimal for these unit-duration assumptions and this chosen conflicting order.
Change the costs or the available execution resources, and the optimisation problem changes. A conflict graph is useful evidence about constraints; it is not a benchmark, a promised confirmation delay or a ranking of blockchains.
Back to contents · Next section
13. Exercise: repair the proposed schedules
Use the original six distinct payer accounts and the original reference order unless a question explicitly changes them.
- A learner proposes Wave A={T1,T2,T6}, Wave B={T3,T4}, Wave C={T5}. Which conflict invalidates Wave A?
- Another learner proposes {T3,T4,T6}, then {T1,T2}, then {T5}. Each wave has no internal conflict. Why is the schedule still wrong?
- Can T4 and T5 share a wave after T1, T2 and T3 have completed?
- If all six share writable payer S, how many conflict edges exist and what is the minimum number of waves in this model?
- If T5 runs before T3 after the original first wave, what value does Z receive?
- Does a compatible pair that calls the same read-only program P become conflicting solely because its program identifier is shared?
Answers and reasoning
- T2 writes Y while T6 reads Y. They cannot execute together in this model, and the selected ordering requires T2 before T6. Moving T6 to Wave B fixes this particular problem.
2. It reverses required dependencies: T3 reads X before T1’s write, T4 changes C before T1 and T2 read it, and T6 reads Y before T2 writes it. Internal compatibility is insufficient without cross-wave ordering.
3. Yes, under the supplied sets. T4 writes C and f4; T5 writes X and f5; they share only read-only P. Their required predecessors have already completed.
4. There are fifteen edges, one for every unordered pair of six transactions. No two can share a wave, so six waves are required. This follows from the changed effective sets, not from any application-counter arithmetic.
5. T1 first makes X=12, then T5 makes X=24, then T3 copies that value. Z becomes 24, which differs from the original required result Z=12.
6. No. Shared read-only P alone creates no read/write conflict. Other accounts must still be checked, including payers and the accounts used by all instructions.
Back to contents · Next section
14. A compact review checklist
Before accepting a statement that several transactions can execute in parallel, ask for the effective account sets, the read-only/writable classification, the reference ordering for conflicts and the assumed resource limits.
Then check each pair, preserve every required dependency, and compare the resulting state with the chosen serial interpretation. Finally, state the scope: this establishes a schedule under declared assumptions, not complete validity, finality or actual wall-clock performance.
This checklist also helps explain a failed claim without blaming the entire architecture. A shared payer, unnecessary writable account or overlooked read dependency may be enough to explain why one proposed group is not independent.
Back to contents · Next section
15. Frequently asked questions
Does a conflict mean the transaction is invalid?
No. It means the two accesses need coordination in this model. Both transactions may execute successfully in an appropriate order. A scheduling constraint is different from a failed signature or program condition.
Are instructions within one transaction parallelised by this worksheet?
No. The worksheet schedules whole transactions. Their internal actions are treated as given, and it does not reorder instructions within a transaction. The pipeline source describes sequential instruction processing.
Does reading the same account require different copies of that account?
No. Shared read-only access is compatible here because neither operation changes it. A concurrent writer would change the analysis and introduce a conflict.
Back to contents · Next section
Sources and next reading
Primary sources checked on 12 October 2026, Singapore time:
- Solana instructions: program, account and data components of an instruction.
- Solana transaction structure: account and signer/read-only information in the described message format. No current format-limit or upgrade-activation conclusion is required here.
- Agave v3.0.0 account handling and locking tests: a pinned implementation reference for shared reads and conflicting write access. Its implementation-specific batch options are not reproduced by the classroom scheduler.
- Solana transaction pipeline: processing and validation responsibilities beyond account-conflict scheduling. Used narrowly, without fee-setting, transaction submission or protocol-limit advice.
Review the earlier deterministic-execution lesson if the comparison with serial state transitions is unfamiliar. The next architecture lesson follows Fabric’s endorsement, ordering and validation stages, where a transaction can be ordered yet fail the checks required to update application state.