Versions Compared

Old Version 1

changes.mady.by.user Mark Ford

Saved on

compared with

New Version 2

changes.mady.by.user Dan Middleton

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
  • Welcome (Mark)
  • Announcing Transact (Shawn)
    • Transact proposal has been moved to the wiki. Bootstrapping is underway.
    • Blog entry has been written based on the proposal. It includes a new diagram that better represents the components. It will be sent to the sponsors soon and then submitted to hyperledger.
      • Are there Which pieces of this diagram that still need to be written (adapters and in memory database, simple key-value)? (Dan)
        • Statice Static adapter and in memory database are in transact. TCP and ZMQ adapters are in progress, same with finishing up the schedulers. Key-value is not inprogressin progress. (Shawn)
      • Fabric has may have recommended a new database backend, I can't remember what it was (Dan)
        • I have not heard that, but I have been looking at Fabric database stuff and it's more like CVS than simple key-value. (Shawn)
          • The versioning there is only there to handle concurrency control. (Todd Little)
      • I've been thinking about how to handle that in Transact, so it can work with Fabric's Read/Write sets. What is serialization format? (Shawn)
        • Protobuf, I don't know about any new database recommendations. (Todd Little)
    • Mailing list, Jira, chat channel are set up. Conversations about permissions are on going. We need to write some text for the Transact Project page. Blog announcement is set for the 11th. We are also working on a logo with Alison Rowan.
  • Introducing the Multi-Project Kanban Board for Transact (Mark)
    • Combined view of Sawtooth, Grid, and Transact, so contributors have an opportunity to see any overlapping work that may exist between projects, and also allow contributors to have one board to go to see all there work. This is also useful for any teams actively working tasks within these projects to have an agile platform too reference and manage from.
    • Includes some quick filters to each project and some active epics. Active filters were added, thanks to Ry. 
    • Two Transact epics that are currently being worked on:
      • Bootstrap HL Transact (much of the work already discussed)
      • Parity w/Sawtooth. I'll talk about a couple of these stories: (Shawn)
        • Lock-free Context Manager, now that we have everything connected, we are revisiting components now that they are more easy to reason about (using channels in rust instead of locks).
        • Command Family RFC is for a smart contract that allows you to specific what actions the smart contract engine will do. For example set, delete, get, sleep for 10 seconds and then do an action, etc. Allows us to write a workload generator to test different scenarios.
        • Finishing the Serial Scheduler. Predecessor Tree is in support of the Parallel scheduler.
        • Transact Documentation is about figuring out what we documentation we want in the rust docs.
    • We strongly encourage people to add stories to the backlog. If you are actively working on the story, move the story to planning and then move the story through the workflow. Feel free to contact me if you have any problems or questions (Mark)
    • Parity with Fabric would be a good epic. (Dan)
      • Yes, but there is some research we need to do before we create the epic. It's good to have an understand what we would need to do, and assemble the tasks first (Shawn)
  • RFC Review
    • Transact - Multi-Database Smart Contracts (Logan)
      • We want to enable smart contracts to read from several database. Only one database is writable(primary), the rest are read only (secondary). All sets and deletes are done on the primary database. This requirement avoids the need to figure out atomic writes to multiple database. RFC forcases on the API that is exposed to the smart contract. We may need to add the read data to the receipts on the transactions so on replay we do not need to reread from the databases.
      • A couple examples may help explain why we think this is interesting: (Shawn)
        • Say we have two sawtooth networknetworks, one includes global data and another that is more restrictive to say only 5 companies. The small network may want to have contracts that update the more restrictive data but is based on data in the global state.
        • Another example is have smart contracts that can read from relational database or key/value database. If everyone on the network has access to that data, the smart contract could reliable reliably access that data. Third example, in sawtooth you cannot make a direct call to get block information (cannot reach into the internals of sawtooth to get that information) instead currently we replicate that information into state. This is a pain point for Mic. Using Transact. , we could provide the blockstore as a read only database to retrieve this block info. 
          • What is the maintaining determinism in the second example? (Dan)
            • One if the database has an identifier and has copy on write. If we are using postgresql, for example, we could use slowing changing dimensions and use block number. It does assume that everyone has access to the database. And finally the transaction receipt stuff logan mentioned before. (Shawn)
      • When a value gets retrieved from a database this information gets logged and stored in the transaction receipt. The database does not need to be available, when replaying the data because it would be available in this transaction receipt. (Logan)
      • It does require some changes to Sawtooth with how it stores the receipts and may need to include a recipets receipt state hash. (Peter)
        • Yes all of this is Sawtooth 2.0 features and is very future-facing. (Shawn)
  • Open Forum
    • We will put up notes for this meeting in a day or so. (Mark)
    • This meeting will be held monthly, with a call for agenda items communicated to the community a week prior to the next meeting. (Mark)