Post #31813

27242b556317d204596bb20c828b2ed7c843d7fa6bd601e88b0688f001b442da
d2f94922e4673463c81b6e3cc6e0b4f964caacfe4c3265c3cb25db9eb3b4e7dd
e2c61429397da55a5ee7749088023feb12e0e8e261dfeba32ee7c0794f9a12f8
Signature verified

The signature from the blockchain entry has been verified against an identity on this server.

{"entry_date":1613470446,"post_data":{"edit_count":3,"last_edit_date":0,"last_edit_user_id":0,"message_sha512":"8e1b097a3f852e248445ee8d4098ac6b6fbbbbfae7c56a7fccf0533bba1423c05273df08f35af7308baeb9cc3701aff8f5265d2c8b601680aed551add9f30357","node_id":115,"post_date":1613470382,"thread_id":5666,"user_id":8},"post_link":"https:\/\/forum.factomprotocol.org\/threads\/sphereon-bv-niels-klomp.5666\/post-31813"}
The entry content as it exists in the database. This should be verified against the blockchain entry.
[Sphereon BV] Niels Klomp
[QUOTE="Anton Ilzheev, post: 31811, member: 35"]
I had convos with some developers in community, we discussed the idea of moving tokens on the protocol level (L1).

L2 solutions is not really popular (even L2 of popular L1’s like Ethereum), and in our case Factom is not popular as L1 itself, so FAT as L2 is not popular at all.

In my opinion tokens balances and transactions should be operated on L1, like in Ethereum. Ethereum has tokens on L1 and it’s pretty straightforward for anyone to create own tokens, which leads new developers into Eth (not only this of course, but it's also important).

I think it’s not too late for Factom to do it. We can use some existing FAT standards and algorithms and implement them on L1, expand Factom libs and factomd APIs.

What do you think about this direction of development for Factom?
[/QUOTE]
I think that is a discussion to be had. I can also see many benefits of having it on layer 2 that are hard to achieve in layer 1 (having superimposed FAT nodes for tokens only in a specific FAT network. Not impacting layer 1 with token changes, bugs and datastructure changes).

For the ease of creating tokens. Obviously it helps that Ethereum basically created the standards for it. But if one would simply package some sidecar docker containers you would have a docker container to spin up to get to develop your tokenization solution with FAT and Factomd in one go.

Moving it to layer 1, means deinvesting a lot of the time and reinvesting that for little to no additional benefits at this point, but with additional costs. Costs that we can and IMO should spent on other things at this point in time. We only have limited manpower and limited resources.

If you or other developers want to investigate, I suggest to create a few research pages/tickets for it, so we can have a proper discussion about it with all interested parties, but IMO it should be a rather compelling story to offset the above points.

So all in all maybe not what you would like to hear at this point in time. I am not sure whether the question would belong in this discussion at all to be honest, but I am happy it did. Because it will show you that I am open and willing to anyone, provided that they do come up with a plan, but as a director I would also have to keep track of any budgets and replacing things that we more or less already have but then maybe a bit more shiny isn't typically the best approach in these types of situations.
This is the raw content, without BBCode parsing.
Top