I think it’s possible that the first real money invoice may happen in 2020.
Dune just released a feature that allows a baker to “lock” the maximum number of rolls they want to be given by the network. This allows bakers to protect themselves against over-delegtaion and gives them the ability to have a bit of liquidity. Do you see a similar feature coming to Tezos? What are the pro/cons of such a solution for protecting against over-delegation?
The latest mainnet branch (released today) fixes a bug in the mempool which caused some endorsements to be missed. More precisely, if endorsements arrived too soon (before the endorsed block was validated), the mempool would reject it. This particular problem should resolve as more and more node upgrade. In the meantime, you can try to play with the endorsement delay parameter to try and make your endorsements arrive a bit later, but of course this is risky as if it arrives too late, you’ll make it worse.
- → TQ Tezos and LIGO have also people working on protocol development
- → Do you mean with an invoice? It happened already with the Brest proposal a few months ago (which didn’t get voted in).
I answered this in a thread above:
Is it possible to begin price discovery on proposal invoices if development is currently being subsidized by Tezos Foundation grants? Seems to defeat the purpose.
I’ve read today the “Enhancing Baking Accounts” post from Awa. Will these options be already included in the next proposal and if so will both be up for bakers’ votes?
These options will most likely be available in 007. It will be up to the community to decide which option they want to choose.
We need to be very cautious with transferring extra data over the peer-to-peer network, but there could be exceptions for specific purposes.
I am not sure about this specific use-case.
One thing we discussed is a way to transmit snapshots or receipts over the network since their integrity can be checked.
I think we need to find a way for price discovery to happen with the TF still present, because otherwise the TF disappears at some point and all the dev work will stop until hopefully we figure out a pricing strategy.
It can take many different forms and I’m planning to write a blog post soonish about it.
Do you have an academic research background in CS or do you rather consider the Cryptium Labs leadership team members to be “hackers” who got into functional programming primarily through passion; or both?
How do you prioritize dedication to the projects you are involved in? How high is your commitment to the Tezos project in particular?
We DaiLambda are working on a new storage sub-system called Plebeia, version controlled append only file system using Merkle Patricia trees. Keeping Merkle hashes of tree nodes, it can provide Merkle proofs very quickly, we can use them to implement trustless wallets. We are currently testing a Tezos node with Plebeia and soon publish a blog/agora report about it. Since Plebeia’s Merkle hash is incompatible with the current Tezos context hash, if we want to fully use Plebeia in Tezos we need a protocol change for the context hash. It requires some more time, maybe in 008.
We also have a very little side project called SCaml, yet another high level language compiles to Michelson. It was born in our joint research with ReFX team of Kyoto university who studies a refinement type system for Michelson to produce sample smart contracts quickly. It is not very powerful language, but small and stable, and we love the name.
I’d say yes. You’d need the following markets:
- “Conditioned on this project getting funded, what is the value of XTZ in a year?”
- “Probability of this project getting funded?”
- “Value of XTZ in a year?”
In this scheme, it does not matter who funds the project (inflation / TF / Fangs).
Having a bittorrent style system for nodes to download snapshots would make bootstrapping a node a breeze.
Adding in a messaging layer for dApps to use for authentication is certainly worth looking into. I want to start by looking into what the state of Ethereum messaging (whisper and ssh) currently is, because then I can give a better fundamented answer.
It would be best to have price discovery begin naturally with individuals or teams that are not receiving a grant or subsidy. Otherwise it would be difficult to separate the two. There is additional work required in research, signaling to see if a proposal is useful, and the added risk of paying for development upfront.
We’d like to see static proofs of gas consumption, at least for some subset of Michelson with reduced expressivity. This would allow to have faster interpretation for those contracts. The Zen protocol had something like this, if I’m not mistaken.
I am personally working on trying to refactor Michelson. The idea being that it should then become much easier to improve it. Some people on the LIGO team might then dabble a bit.
I created two issues (bug reports #513, #516) on Tezos gitlab repo… wait, wait… 9 months ago! They are still open.
Are you working on fixing bugs?
I love the fact that there are several core development teams on Tezos. I’m wondering how existing core devs ie. you will react once previously unknown teams push out potentially competing proposals on chain without communicating this to you at all. Would that be fine? What’s the best way to behave as a new core dev team, from your perspective?
An alternative would be having two different peer-topper networks one that is responsible for handling protocol related tasks and the other that can be used more generically for example in such a wallet dApp communication layer.
Adding to this, besides dApp authentication and communication there are probably various use-cases where it does not make sense to put data directly on the chain but having such a separate communication layer that is still decentralized.