Indonesian
J
our
nal
of
Electrical
Engineering
and
Computer
Science
V
ol.
42,
No.
3,
June
2026,
pp.
892
∼
901
ISSN:
2502-4752,
DOI:
10.11591/ijeecs.v42.i3.pp892-901
❒
892
Smart
contracts
and
a
dual
blockchain
structur
e
f
or
collaborati
v
e
tourism
Zohra
T
emmar
1
,
Asmaa
Boughrara
2
1
Department
of
Computer
Science,
Uni
v
ersity
of
Science
and
T
echnology
of
Oran-Mohamed
Boudiaf,
Oran,
Algeria
2
LSSD
Laboratory
,
Department
of
Computer
Science,
Uni
v
ersity
of
Science
and
T
echnology
of
Oran-Mohamed
Boudiaf,
Oran,
Algeria
Article
Inf
o
Article
history:
Recei
v
ed
Jul
6,
2025
Re
vised
May
4,
2026
Accepted
May
26,
2026
K
eyw
ords:
Blockchain
Consensus
Distrib
uted
system
Smart
contract
T
ourism
ABSTRA
CT
This
article
optimizes
a
decentralized
system
for
collaborati
v
e
tourism
in
Alge-
ria
using
blockchain,
smart
contracts,
and
proof
of
reputation
(PoR)
consensus.
The
system
matches
services
into
or
g
anized
trips,
manages
reserv
ations,
and
automates
payments
t
o
ensure
transparenc
y
and
autonomy
without
centralized
authority
.
This
w
ork
opens
the
door
to
e
xploring
dual-blockchain
architectures.
Building
on
a
pre
vious
w
ork,
we
enhanced
node
interactions,
automated
con-
tract
e
x
ecution,
and
introduced
a
dual-blockchain
structure
to
reduce
latenc
y
while
impro
ving
scalability
and
security
.
This
is
an
open
access
article
under
the
CC
BY
-SA
license
.
Corresponding
A
uthor:
Zohra
T
emmar
Department
of
mathematics
and
Computer
Science,
Uni
v
ersiti
of
Science
and
T
echnology
Oran
El
Mnaouar
,
BP
1505,
Bir
El
Djir
Oran,
Algeria
Email:
zahratemmar@gmail.com
1.
INTR
ODUCTION
Collaborati
v
e
tourism
links
tra
v
elers
directly
with
local
service
pro
viders,
which
creates
pers
onalized
and
authenti
c
e
xperiences
[
1
]
.
The
traditional
tourism
pl
atforms
that
function
using
a
web2
s
tructure
often
suf
fer
from
i
ssues
[2]
such
as
fraud
risks
[3],
easy
manipulation
and
hacking
of
the
cental
authority
,
and
single
point
f
ailure
for
serv
ers
[4],
it
also
lacks
transparenc
y
payments
wise
which
might
complicate
tracking.
This
has
spark
ed
multiple
suggestions
to
adopt
W
eb3
technologies
to
address
these
issues
[5],
[6].
Indeed,
se
v
eral
companies
ha
v
e
already
implemented
blockchain
solutions
to
manage
payments,
re
vie
ws,
and
insurance
claims
[7].
The
w
ork
presented
in
[8]
proposes
adopting
W
eb
3.0
principles,
and
more
specically
blockchain,
to
manage
a
collaborati
v
e
tourism
outside
of
traditional
platforms.
T
o
ensure
f
airness
and
trust,
it
also
optimized
the
proof
of
reputation
(PoR)
consensus
mec
h
a
nism.
While
promising,
that
approach
lack
ed
support
for
smart
contracts
and
a
complete
decentralizati
on
which
defeats
the
purpose
of
the
web3
(eliminating
centralized
authority).
T
o
address
these
g
aps,
our
study
proposes
a
d
e
centralized,
blockchain-based
platform
tailored
for
collaborati
v
e
tourism.
This
w
ork
e
xtends
pre
vious
research
by
inte
grating
smart
contracts
into
the
frame
w
ork
while
introducing
a
dual-blockchain
data
structure.
This
architecture
is
designed
to
lo
wer
latenc
y
and
enhance
user
e
xperience,
while
also
enabling
secure,
transparent,
and
fully
automated
tourism
management.
2.
CONTEXT
WEB3:
or
decentralized
web,
is
a
web
space
that
al
lo
ws
people
to
interact
with
a
mutual
trust
that
is
set
by
the
technology
of
blockchain
itself.
An
ideal
W
eb3
infrastructure
should
not
include
a
middleman
that
J
ournal
homepage:
http://ijeecs.iaescor
e
.com
Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian
J
Elec
Eng
&
Comp
Sci
ISSN:
2502-4752
❒
893
has
an
y
po
wer
o
v
er
the
netw
ork,
and
no
w
since
2020
multiple
elds
had
started
emer
ging
their
services
into
the
blockchain,
chasing
the
security
and
inte
grity
it
of
fers
[9].
Blockchain:
is
a
decentralized
technology
that
stores
data
across
multiple
nodes,
enabling
real-tim
e
information
e
xchange
without
a
central
authority
[10].
It
ensures
transparenc
y
,
security
,
and
tamper
-resistant
record
k
eeping
through
cryptograph
y
.
Blockchain
is
based
on
k
e
y
principles
including
distrib
uted
data
shar
-
ing,
peer
-to-peer
communication,
transparenc
y
with
pseudon
ymity
,
irre
v
ersibility
of
records,
smart
contract
e
x
ecution,
and
consensus
among
participants
[11].
Consensus:
is
an
algorithm
and
a
technique
to
ensure
the
public
nodes
in
a
blockchain
netw
ok
are
trusted
and
responsible
for
data
updates
by
gi
ving
a
form
of
v
alidity
to
the
ne
w
data.
There
are
multiple
types
of
consensus
algorithms,
such
as
Proof
of
W
ork
and
Proof
of
Stak
e,
[12],
which
dif
fer
in
ho
w
nodes
are
selected
to
v
alidate
and
add
ne
w
blocks
to
the
blockchain,
and
also
Proof
of
Reputation
which
is
the
consensus
used
in
this
w
ork.
Proof
of
reputation:
a
consensus
mechanism
that
uses
reputation,
rather
than
digital
tok
ens
as
the
main
incenti
v
e
for
par
ticipation.
In
PoR,
nodes
with
strong
reputations
are
selected
to
v
alidate
and
publish
blocks
[13].
This
mechanism
uses
the
beha
vior
of
nodes
within
themselv
es
o
v
er
a
period
of
time
to
determine
their
reputation
v
alue
.
It
then
uses
that
v
alue
to
determine
a
set
of
nodes
responsible
for
creating
data
and
updating
and
preforming
tasks
within
the
netw
ork
[14].
3.
B
A
CKGR
OUND
3.1.
Related
w
ork
In
the
conte
xt
of
inte
grating
blockchain
in
the
tourism
eld
there
are
some
rem
arkable
w
ork
i
n
the
pas
t
recent
years
such
as
T
ra
v
ala,
XcelT
rip,
and
LockT
rip,
[15]
that
emplo
y
blockchain
technology
for
decentralized
cryptocurrenc
y
payments,
transparent
booking
transactions,
and
tok
en-based
lo
yalty
and
re
w
ard
systems,
aim-
ing
to
reduce
intermediary
fees,
increase
trust
between
users
and
or
g
anizations,
and
enhance
payment
security
.
Still,
their
use
of
blockchain
is
limited
to
the
nancial
layer
rather
than
trip
planning
and
pro
viding
the
service.
Be
yond
tourism,
blockchain
has
been
e
xtensi
v
el
y
studied
in
other
application
areas,
such
as
secure
biological
data
sharing
through
federated
learning
frame
w
orks
(BIOCHAIN
[16]),
pro
v
enance
tracking
and
inte
grity
v
erication
of
digital
te
xtual
content
(CER
V
ANTES
[17]),
and
supply
chain
management
to
impro
v
e
transparenc
y
,
traceability
,
and
resistance
to
fraud
(Cho
wdhury
[18]).
3.2.
Ov
er
view
of
the
w
ork
to
optimize
The
approach
proposed
in
[8]
aims
to
help
service
pro
viders
(guides,
housing
pro
viders,
and
trans-
porters)
of
fer
their
services,
enabling
tra
v
elers
to
easily
consult
and
book
trips.
When
the
service
pro
viders
submit
their
services,
the
y
get
matched
together
to
form
a
trip
package.
This
process
happens
when
their
infor
-
mation
match
in
date
and
location.
The
matching
happens
in
a
centralized
serv
er
,
and
the
n
the
ne
w
data
gets
transferred
to
the
blockchain
netw
ork
that
is
responsible
for
the
reserv
ation
for
the
clients.
Once
a
reserv
ation
is
made,
the
netw
ork
initiates
a
node
election
process
to
identify
a
leader
for
block
creation.
The
selected
leader
adds
the
reserv
ation
data
into
a
ne
w
block,
utilizing
PoR
as
the
underlying
consensus
protocol.
The
PoR
consensus
w
as
proposed,
where
v
oting
a
leader
depends
on
the
reputation
of
nodes
that
is
determined
by
tw
o
parameters:
score
(the
number
of
times
a
node
has
been
elected
as
the
leader),
and
weight
(a
normalized
v
alue
of
the
Score
to
pre
v
ent
nodes
from
dominating
the
selection
process),
to
help
promoting
decentralization.
While
e
x
ecuting
the
consensus,
all
nodes
in
the
netw
ork
are
concerned
of
the
v
oting
process
to
insure
a
f
air
selection.
Just
lik
e
proof
of
w
ork
consensus,
this
consensus
focuses
on
security
(ensuring
f
air
selection)
and
decentralization
(all
nodes
are
concerned
with
the
v
oting
process)
while
sacricing
a
good
amount
of
scalability
(according
to
the
Three-Dimensional
T
radeof
fs
for
Consensus
Algorithms
[19])
3.3.
Limits
of
the
appr
oach
to
optimize
Comple
xity:
the
multi-step
v
oting
process
for
consensus
introduces
additional
comple
xity
,
which
can
lead
to
increased
latenc
y
,
especially
as
the
netw
ork
gro
ws.
Reputation
system
e
xploitation:
the
PoR
mechanism
is
vulnerable
to
collusion.
Malicious
nodes
can
coordinate
to
articially
inate
their
reputation
through
f
alse
v
alidations,
e
v
entually
leading
to
a
centralized
tak
eo
v
er
of
the
netw
ork.
Centralization:
this
w
ork
w
as
not
fully
decentralized
when
coming
to
generating
trips
since
the
or
g
anization
serv
er
w
as
the
entity
cross
matching
the
trips
and
sending
it
to
the
nodes,
which
is
what
we
are
looking
to
a
v
oid
when
choosing
to
decentralize
the
system.
Smart
contracts
and
payment
automation:
this
w
ork’
s
conception
and
e
x
ecution
didn’
t
include
Smart
contr
acts
and
a
dual
bloc
kc
hain
structur
e
for
collabor
ative
tourism
(Zohr
a
T
emmar)
Evaluation Warning : The document was created with Spire.PDF for Python.
894
❒
ISSN:
2502-4752
the
smart
contracts
concept
and
the
automation
of
payments
as
it
w
as
left
unnished
due
to
the
lack
of
time.
And
for
these
reasons
and
problems
we
ha
v
e
decided
to
restructure
this
approach
to
get
an
impro
v
ed
rened
approach
that
will
be
e
xplained
in
the
ne
xt
section
4.
PR
OPOSED
APPR
O
A
CH
Our
proposed
approach
decentralized
the
services
matching
and
trips
management
and
inte
grated
the
concept
of
smart
contracts
to
manage
the
payments
within
the
nodes
automatically
,
this
w
as
done
without
retouching
the
consensus
method,
only
re-implementing
it.
4.1.
The
ar
chitectur
e
of
the
pr
oposed
appr
oach
Our
approach
w
as
structured
into
3
dif
ferent
layers:
Application
layer:
the
interf
ace
gi
v
en
to
the
user
to
interact
with
(login,
of
fer
services,
and
parti
cipate
in
trips)
Netw
ork
g
ate
w
ay:
this
layer
manages
the
communication
be
tween
the
blockchain
netw
ork
and
the
application
layer
,
it
is
a
g
ate
w
ay
between
the
users
en
vironment
and
the
blockchain
netw
ork,
it
also
ensures
the
well
management
of
the
platform.
Blockachain
layer:
this
layer
includes
2
seperate
modules:
−
Netw
ork
module:
this
module
manages
the
synchronization
of
the
nodes
(managing
the
consensus,
the
reputation
system,
broadcasting
the
results
and
processing
what
has
been
recei
v
ed).
−
Smart
Contract
module:
this
module
is
what
manages
the
trips
part
(depl
o
y
i
ng
and
e
x
ecuting
the
smart
contracts,
updating
the
trip
blocks,
v
erifying
the
nished
trips
and
e
x
ecuting
the
payments).
4.2.
Actors
and
components
The
user
:
W
e
ha
v
e
tw
o
types
of
users:
a)
Simple
user:
upon
re
gistration,
the
user
can
select
to
interact
as
a
si
mple
user
(someone
looking
for
reser
-
v
ations).
A
normal
user
can
bro
wse
a
v
ailable
trips
and
reserv
e
spots
as
desired,
complete
the
reserv
ation
process
by
making
the
payment
,
vie
w
a
list
of
trips
the
y
ha
v
e
successfully
reserv
ed,
and
access
and
edit
their
personal
prole.
b)
Service
pro
vider:
during
re
gistration,
a
user
may
also
choose
to
interact
as
a
service
pro
vider
(e.g.,
guide,
transporter
,
or
host).
A
service
pro
vider
can
submit
a
service
of
feri
ng
to
be
matched
within
a
trip
package,
vie
w
a
list
of
their
submitted
services
and
see
which
trips
the
y
ha
v
e
been
matched
to,
and
access
and
vie
w
the
prole.
The
node:
In
this
system,
the
node
has
tw
o
states
of
functioning
a)
The
node
in
a
normal
state
:
the
node
can:
participate
in
a
consensus
and
broadcast
the
results,
or
g
anize
the
consensus
when
randomly
chosen
by
the
netw
ork
g
ate
w
ay
,
and
v
alidate
then
accept
or
reject
recei
v
ed
data.
b)
The
node
as
a
leader:
When
an
election
is
done
(as
sho
wn
in
the
pre
vious
w
ork)
a
node
can
possibly
be
chosen
to
be
a
leader
which
gi
v
es
it
access
to
e
x
ecuting
and
deplo
ying
smart
contracts,
generating
ne
w
data
and
broadcasting
it,
distrib
uting
payments,
and
re
gistering
a
ne
w
node
in
the
netw
ork.
4.3.
The
smart
contracts
4.3.1.
The
trip
planning
smart
contract:
This
smart
contract
automates
the
creat
ion
of
ne
w
trip
packages
and
secure
their
e
x
ecution,
while
conserving
the
rights
of
service
pro
viders
and
applying
a
tick
eting
system
for
the
participators.
The
template
of
the
smart
contract
is
stored
in
the
genesis
block
of
the
trip
planning
blockchain
in
decimal
format.
4.3.2.
The
payment
smart
contract
This
smart
contract
ensures
and
secures
payments
for
service
pro
viders.
When
a
reserv
ation
is
made,
the
payments
get
collected.
Then,
after
the
trip
is
o
v
er
,
the
service
pro
viders’
shares
are
distrib
uted
to
their
accounts.
This
smart
contract
acts
as
a
le
g
al
contract
for
this
agreement
and
is
what
ensures
this
process.
Indonesian
J
Elec
Eng
&
Comp
Sci,
V
ol.
42,
No.
3,
June
2026:
892–901
Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian
J
Elec
Eng
&
Comp
Sci
ISSN:
2502-4752
❒
895
4.4.
The
pr
oposed
blockchain
f
ormat
Our
approach
modied
the
con
v
entional
blockchain
model
by
introducing
a
dual-chain
archit
ecture,
where
tw
o
completely
separate
b
ut
interacti
v
e
blockchains
were
used
to
manage
dif
ferent
functions
within
the
system.
Both
blockchains
e
xist
in
e
v
ery
node
in
the
system,
and
when
the
node
is
acti
v
e
and
interacting,
the
blockchains
are
triggered
to
write
ne
w
data,
update,
or
fetch
in
a
completely
separate
w
ay
.
4.4.1.
T
rip
planning
blockchain
Genesis:
the
genesis
is
generated
automatically
when
a
ne
w
node
is
rst
launched,
and
it
will
c
o
nt
ain
the
same
data
for
all
nodes(the
template
of
the
trip
planning
smart
contract).
T
rip
information
block:
this
type
of
block
contains
the
trips
data
including:the
inde
xing
and
time
stamp
of
the
block,
the
ne
w
trip
data
(location,
start
date,
end
date,
price,
spots,
a
v
ailable
spots,
etc.),
including
the
services
data,an
object
that
st
ores
and
manages
spots(IDs
and
spots
reserv
ed),a
ag
determ
ining
the
state
of
the
trip
(if
payed
or
not),
and
the
current
and
pre
vious
block
hashes
for
security
.
4.4.2.
The
payments
blockchain
Genesis:
the
genesis
is
generated
automatically
when
a
ne
w
node
is
rst
launched,
and
it
will
contain
the
same
data
for
all
nodes(the
template
of
the
payment
smart
contract).
P
ayment
smart
contract
block:
this
type
of
block
contains
the
payment
contract
data
including:
the
inde
x,
creation
timestamp
of
the
block,
the
trip
ID
related
to
this
payment,
the
e
x
ecution
date,
the
data
required
for
payment
distrib
ution
(service
IDs,
bank
accounts,
and
requested
amounts),
the
smart
contract
e
x
ecution
ar
guments
(a
string
of
ar
gs
for
the
system),
and
the
current
and
pre
vious
block
hashes
for
security
.
4.5.
The
dual
blockchain
The
trip
blockchain
focuses
solely
on
trip
planning,
while
the
payments
blockchain
ensures
secure
nancial
operations.
W
e
chose
this
architecture
to
reduce
c
o
m
ple
xity
for
simple
tas
ks.
When
a
user
bro
wses
the
platform,
trips
are
fetched
from
nodes
with
limited
resources.
By
isolating
trip
data
from
nancial
transactions
(smart
contracts),
these
nodes
a
v
oid
processing
a
big
chunk
of
data
for
simple
operations
lik
e
displaying
trips.
Also,
this
s
eparation
allo
ws
each
blockchain
to
e
v
olv
e
independently
.
The
payments
blockchain
can
prioritize
security
,
while
the
trip
blockchain
can
be
optimized
for
lo
wer
latenc
y
and
a
better
user
e
xperience.
4.6.
The
pr
oposed
appr
oach
pr
ocess
The
general
process
of
the
approach
go
through
multiple
steps:
4.6.1.
Registering
a
new
node
T
o
re
gister
a
ne
w
node,
the
system
must
assign
it
a
representati
v
e.
As
sho
wn
in
Figure
1,
the
g
ate
w
ay
recei
v
es
the
join
request,
sa
v
es
it,
and
triggers
a
netw
ork
consensus.
Once
a
representati
v
e
is
selected,
the
g
ate
w
ay
sends
its
address
to
the
ne
w
node
to
continue
the
re
gistration.
Figure
1.
Assigning
a
representati
v
e
for
the
re
gistration
Smart
contr
acts
and
a
dual
bloc
kc
hain
structur
e
for
collabor
ative
tourism
(Zohr
a
T
emmar)
Evaluation Warning : The document was created with Spire.PDF for Python.
896
❒
ISSN:
2502-4752
After
assigni
ng
the
representat
i
v
e,
the
ne
w
node
sends
the
re
gistration
request
to
the
elected
repre-
sentati
v
e.
The
representati
v
e
ne
xt
re
gisters
the
node
within
its
o
wn
database,
then
broadcasts
a
request
in
the
netw
ork
to
ensure
the
ne
w
node
is
re
gistered
in
all
parts
of
the
netw
ork,
while
also
sharing
the
netw
ork
data
and
the
database
with
the
ne
w
node.
4.6.2.
Submitting
a
ser
vice
As
sho
wn
in
Figure
2,
this
process
starts
when
a
servi
ce
pro
vider
submits
a
service
to
the
netw
ork
g
ate
w
ay
,
the
g
ate
w
ay
ne
xt
sends
a
consensus
request
to
a
randomly
selected
node,
that
node
will
launch
and
manage
the
consensus
until
it
is
nished,
then
it
will
share
the
result
(the
leader)
with
the
g
ate
w
ay
,
the
g
ate
w
ay
then
will
send
the
request
to
the
leader
,
the
leader
will
process
the
request,
broadcast
the
results,
and
reply
with
the
results
to
the
g
ate
w
ay
,
the
g
ate
w
ay
will
share
the
results
with
the
service
pro
vider
.
Figure
2.
Submitting
a
service
through
the
system
When
the
leader
recei
v
es
the
request
to
add
a
service.
it
starts
by
e
xtracting
the
smart
contract
templ
ate
from
the
genisis
and
translating
it
from
byte
to
code
format.
When
the
template
is
ready
,
the
code
gets
e
x
ecuted
so
it
sa
v
es
the
ne
w
service
into
the
database
and
goes
through
all
the
a
v
ailable
services
looking
to
match
them
into
a
ne
w
generated
trip.
If
a
match
is
found
it
generates
a
trip,
if
not
it
sa
v
es
the
service
back
into
the
database.
When
the
e
x
ecution
is
o
v
er
the
ne
w
produced
data
(either
a
ne
w
trip
or
a
ne
w
service)
gets
broadcasted
to
the
rest
of
the
netw
ork
and
shared
with
the
g
ate
w
ay
.
4.6.3.
P
articipating
in
a
trip
The
process
of
adding
a
participation
through
the
netw
ork
is
the
same
as
adding
a
ne
w
service
(t
hat
has
been
e
xplained
earlier)
only
with
one
step
added,
which
is
v
erifying
the
payment,
this
step
is
done
by
the
netw
ork
g
ate
w
ay
through
P
ayP
al
right
aft
er
the
submission
of
the
request
by
the
user
.
As
sho
wn
in
Figure
3,
when
the
leader
recei
v
es
the
participation
request,
it
proceeds
with
deplo
ying
a
ne
w
block
of
the
payment
smart
contract
that
contains
the
data
needed
for
later
e
x
ecution.
Then
it
will
create
a
ne
w
trip
block
updating
the
trip
data
to
include
this
ne
w
participation,
both
these
blocks
will
be
ne
xt
shared
with
the
netw
ork.
Figure
3.
Flo
w
diagram
for
the
leader
processing
a
participation
request
4.6.4.
V
erifying
and
distrib
uting
payment
After
a
trip,
the
service
pro
viders
e
xpect
a
payment
for
thier
services,
which
are
done
this
process
:
This
process
starts
when
the
time
trigger
goes
of
f
in
the
g
ate
w
ay
,
this
time
trigger
is
important
to
mak
e
sure
all
payments
are
deli
v
ered
on
time,
its
result
will
be
a
consensus
request
sent
to
a
randomly
selected
node,
the
node
will
launch
a
consensus
through
the
netw
ork
and
when
done,
the
result
(the
leader)
is
shared
with
the
g
ate
w
ay
,
the
g
ate
w
ay
ne
xt
randomly
selects
another
node
and
contacts
it
to
v
erify
the
v
alidity
of
the
leader
address
(this
step
is
for
e
xtra
security
since
the
leader
will
ha
v
e
access
to
funds).
Indonesian
J
Elec
Eng
&
Comp
Sci,
V
ol.
42,
No.
3,
June
2026:
892–901
Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian
J
Elec
Eng
&
Comp
Sci
ISSN:
2502-4752
❒
897
After
the
leader
is
selected
and
the
en
vironment
is
ready
,
as
sho
wn
in
Figure
4,
the
v
e
rication
proc
ess
starts
when
the
g
ate
w
ay
sends
the
v
erication
request
along
with
a
P
ayP
al
tok
en
to
the
leader
.
The
leader
then
will
process
the
request
then
distrib
ute
the
payments,
broadcast
the
results,
and
share
the
results
with
the
g
ate
w
ay
all
at
once,
the
g
ate
w
ay
ne
xt
will
notify
the
users.
Figure
4.
V
erifying
the
trips
through
the
netw
ork
As
sho
wn
in
Figure
5,
when
the
leader
recei
v
es
the
request,
it
will
start
by
searching
through
the
trips
blockchain
looking
for
trips
that
are
o
v
er
b
ut
not
yet
payed,
when
done,
it
ag
ain
goes
through
the
payment
blockchain
looking
the
payments
related
to
those
trips,
when
the
search
is
done
the
leader
e
x
ecutes
the
smart
contracts
and
produces
a
ne
w
trip
block
for
each
trip
to
update
it
as
payed,
ne
xt
the
leader
will
distrib
ute
the
payments
using
the
recei
v
ed
tok
en,
broadcast
the
results,
and
notify
the
g
ate
w
ay
.
Figure
5.
Flo
w
diagram
of
v
erifying
the
trips
within
the
leader
5.
EXPERIMENTING
5.1.
De
v
elopment
en
vir
onment
T
o
impl
ement
the
approach
we
ha
v
e
used
a
leno
v
o
thinkpad
laptop
with
an
i5
-
3600U
cpu,
8gb
ddr4
Ram
and
512gb
solid
state
dri
v
e.
for
softw
are
we
utilized
Express
,
V
ueJs,
HTML,
CSS,
Postgress
v16,
and
paypal
sdks
[20].
The
implementation
required
3449
lines
of
code
distrib
uted
on
36
dif
ferent
scripts.
5.2.
T
esting
and
e
v
aluating
W
e
e
v
aluated
se
v
eral
platforms
before
deciding
to
b
uild
from
scratch
to
ensure
full
customization
of
the
node,
netw
ork,
and
consensus.
Our
testing
included
Hyperledger
F
abric
[21]
(Golang),
which
we
found
too
enterprise-oriented,
as
well
as
Ethereum
[22]
and
Solana
[23].
Although
we
implemented
smart
contracts
in
Solidity
,
Vyper
,
and
Rust,
these
platforms
were
ultimately
unsuitable
due
to
their
predetermined
consensus
mechanisms.
A
precise
comparison
is
not
feasible,
as
our
custom
de
v
elopment
w
as
dri
v
en
specically
by
the
lack
of
an
e
xisting
platform
meeting
our
requirements.
W
e
considered
while
testing
that
the
platform
is
limits
the
trips
creations
in
order
to
lo
wer
competition
(there
cannot
be
multiple
trips
with
the
same
time
and
location),
the
e
v
aluation
w
as
done
by
testing:
5.2.1.
The
r
esour
ces
usage
The
payment
v
erications
resources
usage
P
ayment
v
erication
occurs
when
a
node
is
selected
to
v
erify
and
payout
trips
as
sho
wn
in
Figure
6.
This
includes
both
v
erication
and
result
broadcasting.
Each
trip
Smart
contr
acts
and
a
dual
bloc
kc
hain
structur
e
for
collabor
ative
tourism
(Zohr
a
T
emmar)
Evaluation Warning : The document was created with Spire.PDF for Python.
898
❒
ISSN:
2502-4752
requires
the
processing
about
40
blocks
per
10
trips.
The
follo
wing
data
illustrates
the
resource
usage
of
this
process.
As
sho
wn
in
T
able
1
the
gro
wth
rate
de
v
elops
in
lo
w
v
alues.
Figure
6.
The
payment
v
erications
resources
usage
(percentage
of
CPU
usage)
T
o
e
v
aluate
the
results
we
ha
v
e
used
the
gro
wth
rate:
Gro
wth
Rate
=
Resource
Usage
100
nodes
−
Resource
Usage
10
nodes
90
(1)
T
able
1.
Gro
wth
rate
per
node
for
dif
ferent
w
orkloads
Metric
10
trips
20
trips
30
trips
A
v
erage
Gro
wth
Rate
(units/node)
0.025
0.0096
0.028
0.021
Recei
ving
and
v
alidating
the
payment
v
erications
resources
usage
In
this
case
the
resources
usage
depends
solely
on
the
number
of
blocks
recei
v
ed,each
trip
has
4
reserv
ations
which
means
v
alidating
about
40
blocks
for
each
10
trips.
As
sho
wn
in
Figure
7,
although
the
resource
usage
gro
ws
consistentl
y
with
node
count,
the
gro
wth
rate
of
R=0.22
is
a
high
rate
and
sho
ws
that
this
process
may
require
optimi
zation
at
lar
ger
scales.
Figure
7.
Recei
ving
and
v
alidating
the
payment
v
erications
(%
of
resources
usage
per
number
of
nodes)
Comparison
with
the
pre
vious
w
ork:
the
pre
vious
w
ark
of
[8]
e
v
aluated
the
results
using
the
resources
usage
of
the
de
v
eloped
proof
of
reputation
consensus.
T
o
grasp
our
progress
we
will
be
comparing
our
imple-
mentation
results
with
the
results
sho
wn
in
that
w
ork.
Sho
wn
ne
xt
is
the
2
results
compared
by
the
resources
usage
of
the
rst
and
second
round
of
the
consensus.
Scaling
the
pre
vious
w
ork
to
35
nodes
caused
netw
ork
jamming
and
errors
during
result
e
xchange.
By
restructuring
the
architecture
and
re-implementing
the
consensus,
we
resolv
ed
these
issues
and
achie
v
ed
smoother
e
x
ecution.
As
sho
wn
i
n
Figure
8,
our
implementation
signicantly
reduced
CPU
usage,
reaching
a
37.2%
impro
v
ement
o
v
er
the
original
w
ork.
Indonesian
J
Elec
Eng
&
Comp
Sci,
V
ol.
42,
No.
3,
June
2026:
892–901
Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian
J
Elec
Eng
&
Comp
Sci
ISSN:
2502-4752
❒
899
Figure
8.
Comparison
with
the
w
ork
proposed
in
[8]
Impro
v
ement
(%)
=
Resource
usage
of
[6]
−
Resource
usage
of
our
w
ork
Resource
usage
of
[6]
×
100
=
37
.
2%
(2)
5.3.
Ev
aluation
of
the
security
W
e
ha
v
e
only
applied
supercial
simple
security
tests
to
ensure
the
archi
tecture
is
functional,we
are
aiming
to
apply
more
comple
x
detailed
tests
in
the
future
after
de
v
eloping
the
w
ork
more.
5.3.1.
A
man
in
the
middle
attack
(tempering
with
cr
eated
data)
In
a
10-node
netw
ork
with
one
malicious
actor
,
an
elected
leader’
s
broadcast
is
intercepted
before
reaching
the
nodes.
The
attack
er
tampers
with
the
data
and
rebroadcasts
it.
Ho
we
v
er
,
the
nodes
reject
these
blocks
as
in
v
alid.
After
conrming
the
leader’
s
identity
,
each
node
v
eries
the
block’
s
hash;
since
the
tampered
hash
does
not
match,
the
block
is
discarded.
5.3.2.
A
malicious
node
br
oadcasting
fak
e
blocks
In
a
10-node
netw
ork
with
one
malicious
actor
,
the
attack
er
broadcasts
a
block
containing
seem
ingly
v
alid
data
and
hashes
signed
wit
h
its
o
wn
pri
v
ate
k
e
y
.
The
netw
ork
consistently
reject
s
these
blocks.
Before
data
v
alidation,
nodes
v
erify
the
creatorNodeUrl
and
consult
the
”leaders
array”
to
ensure
the
sender
is
the
authorized
consensus
leader
.
Since
the
malicious
node
is
not
the
designated
leader
,
the
block
is
discarded.
5.4.
Limitations
The
project
is
limited
by
the
lack
of
further
e
xploration
into
scalability
,
the
w
ork
could
also
use
more
detailed
testing
to
test
the
s
ecurity
.
Also
since
we
did
not
optimize
the
consensus
itself
it
w
ould
still
strug-
gle
from
Reputation
System
Exploitation
issues
we
ha
v
e
mentioned
before.
Future
w
ork
could
optimize
the
w
ork
by
inte
grating
re
w
ard
mechanisms,
optimizing
the
tw
o
blockchains
separately
since
the
y
serv
e
dif
ferent
purposes,
and
enhancing
node
beha
vior
to
detect
and
isolate
malicious
actors.
6.
CONCLUSION
In
this
w
ork,
we
impro
v
ed
and
optimi
zed
a
Decentralized
solution
for
Collaborati
v
e
T
ourism.
A
blockchain
and
smart
contract
based
system
that
enables
trip
or
g
anization,
reserv
ations,
and
automated
pay-
ments.
W
e
ha
v
e
managed
to
enhance
scalability
and
impro
v
e
the
decentralization
compared
to
the
pre
vious
w
ork.
This
w
as
done
by
proposing
a
dual
blockchain
architecture.
Ov
erall,
this
w
ork
demonstrates
clear
im-
pro
v
ements
and
pro
vides
a
solid
foundation
for
future
de
v
elopments,
particularly
in
e
xpanding
node
beha
vior
and
impro
ving
the
request
handling
to
include
re
w
arding
data-creating
nodes.
FUNDING
INFORMA
TION
Authors
state
no
funding
in
v
olv
ed.
Smart
contr
acts
and
a
dual
bloc
kc
hain
structur
e
for
collabor
ative
tourism
(Zohr
a
T
emmar)
Evaluation Warning : The document was created with Spire.PDF for Python.
900
❒
ISSN:
2502-4752
A
UTHOR
CONTRIB
UTIONS
ST
A
TEMENT
This
journal
uses
the
Cont
rib
utor
Roles
T
axonomy
(CRediT)
to
recognize
indi
vidual
author
contrib
u-
tions,
reduce
authorship
disputes,
and
f
acilitate
collaboration.
Name
of
A
uthor
C
M
So
V
a
F
o
I
R
D
O
E
V
i
Su
P
Fu
Zohra
T
emmar
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
Asmaa
Boughrara
✓
✓
✓
✓
✓
✓
✓
✓
C
:
C
onceptualization
I
:
I
n
v
estig
ation
V
i
:
V
i
sualization
M
:
M
ethodology
R
:
R
esources
Su
:
Su
pervision
So
:
So
ftw
are
D
:
D
ata
Curation
P
:
P
roject
Administration
V
a
:
V
a
lidation
O
:
Writing
-
O
riginal
Draft
Fu
:
Fu
nding
Acquisition
F
o
:
F
o
rmal
Analysis
E
:
Writing
-
Re
vie
w
&
E
diting
CONFLICT
OF
INTEREST
ST
A
TEMENT
Authors
state
no
conict
of
interest.
D
A
T
A
A
V
AILABILITY
The
data
that
support
the
ndings
of
this
study
will
be
a
v
ailable
in:
https://github
.com/zahrat
emmar/
tripPlanner
.git
REFERENCES
[1]
D.
Getz
and
T
.
B.
Jamal,
“The
en
vironment–community
symbiosis:
A
case
for
collaborati
v
e
tourism
planning,
”
J
ournal
of
Sustain-
able
T
ourism
,
v
ol.
2,
no.
3,
pp.
152–173,
1994.
[2]
M
.
E.
Noti,
“W
eb
2.0
and
its
inuence
in
the
tourism
sector
,
”
European
Scientic
Journal
,
v
ol.
9,
no.
20,
2013.
[3]
S
.
A.
Ansar
,
J.
Y
ada
v
,
S.
K.
Dwi
v
edi,
and
A.
P
ande
y
,
“
A
critical
analysis
of
fraud
cases
on
the
internet,
”
T
urkish
Journal
of
Computer
and
Mathematics
Education
,
v
ol.
12,
no.
1,
pp.
424–445,
2021.
[4]
N.
A.
Saqib,
A.
A.
Salam,
A.-U.
Rahman,
and
S.
Dash,
“Re
vie
wing
risks
and
vulnerabilities
in
web
2.0
for
matching
securi
ty
con-
siderations
in
web
3.0,
”
Journal
of
Discrete
Mathematical
Sciences
and
Cryptograph
y
,
2021,
doi:
10.1080/09720529.2020.1857903.
[5]
D.
Duz
iak,
“Blockchain
for
Hospitality
and
T
ourism,
”Apress
LP
,
2023.
[6]
Y
.
F
an,
B.
Lin,
and
Y
.
Lin,
“W
eb3-enabled
technol
ogies
in
tourism
b
usinesses:
a
multi-method
study
of
user
trust,
lo
yalty
,
and
tangible
economic
outcomes,
”
T
ourism
Re
vie
w
,
Aug.
2025.
doi:
10.1108/TR-03-2025-0293.
[7]
I.
¨
Onder
and
U.
Gunter
,
“Blockchain:
Is
it
the
future
for
the
tourism
and
hospitality
industry?”
J
ournal
of
V
acati
on
Mark
eting
,
v
ol.
28,
no.
2,
pp.
135–150,
2022,
doi:
10.1177/1354816620961707.
[8]
A.
Boughrara,
N.
A.
Daoud,
and
N.
L.
Harkati,
“
Automated
or
g
anized
tour
planning
with
blockchain:
An
inno
v
ati
v
e
solution,
”
International
J
ournal
of
Intellig
ent
Information
and
Database
Systems
,
v
ol.
18,
no.
2,
2026,
doi:10.1504/IJIIDS.2025.10074152.
[9]
Q.
W
ang,
R
.
Li,
Q.
W
ang,
S.
Chen,
M.
Ryan,
and
T
.
Hardjono,
“Exploring
W
eb3
from
the
vie
w
of
blockchain,
”
2022.
[10]
A.
A.
T
alib,
M.
H.
Abdulkareem,
S.
N.
Selman,
and
S.
A.
T
alib,
“Impact
blockchain
technology
on
t
raditional
electronic
payment
system,
”
Indonesian
Journal
of
Electrical
Engineering
and
Computer
Science
,
v
ol.
32,
no.
3,
pp.
1703–1711,
Dec.
2023,
doi:
10.11591/ijeecs.v32.i3.pp1703-1711.
[11]
M.
Iansiti
and
K.
R.
Lakhani,
“The
T
ruth
About
Blockchain,
”
Harvar
d
Business
Re
vie
w
,
v
ol.
95,
no.
1,
pp.
119–127,
2017.
[12]
C.
Menk
el-Meado
w
,
ed.,
“Multi-party
dispute
resolution,
democrac
y
and
decision-making,
”
Comple
x
Dispute
Resolution
,
v
ol.
2,
Routledge,
2012,
p.
602.
ISBN:
978-0-7546-2799-9.
[13]
F
.
Gai,
B.
W
ang,
W
.
Deng,
and
W
.
Peng,
“Proof
of
reputation:
A
reputation-based
consensus
protocol
for
peer
-to-peer
netw
ork,
”
2018.
[14]
O.
Aluk
o
and
A.
K
olonin,
“Proof-of-reputation:
An
alternati
v
e
consensus
mechanism
for
blockchain
systems,
”
International
J
ournal
of
Network
Security
&
Its
Applications
(IJNSA)
,,
v
ol.
13,
no.
4,
Jul.
2021,
doi:
10.5121/ijnsa.2021.13403.
[15]
J.
M.
Luo
and
Z.
W
.
Hu,
“Blockchain
technology-based
b
usiness
model:
A
case
study
of
tra
v
el
sites,
”
J
ournal
of
T
ourism
Quarterly
,
v
ol.
5,
no.
3–4,
pp.
59–76,
2023.
[16]
V
.
Bonnici,
V
.
Arceri,
A.
Diana,
F
.
Bertini,
E.
Iotti,
A.
Le
v
ante,
V
.
Bernini,
E.
Ne
viani,
and
A.
Dal
P
al
`
u,
“BIOCHAIN:
T
o
w
ards
a
platform
for
securely
sharing
microbiological
data,
”
in
Pr
oc.
Int.
Database
Engineer
ed
Applicati
ons
Symposium
(IDEAS
2023)
,
Heraklion,
Crete,
Greece,
May
05–07,
2023,
pp.
1–5,
A
CM,
doi:
10.1145/3589462.3589501.
[17]
F
.
Bertini,
A.
Benetton,
and
D.
Montesi,
“Ensuring
ne
ws
inte
grity
ag
ainst
online
information
disorder
thr
ough
te
xt
w
atermark-
ing
and
blockchain,
”
Bloc
kc
hain:
Resear
c
h
and
Applications
,
in
press,
a
v
ailable
online
31
October
2025,
article
100414,
doi:
10.1016/j.bcra.2025.100414.
[18]
R.
H.
Cho
wdhury
,
“
Automating
supply
chain
management
with
blockchain
technology
,
”
W
orld
J
ournal
of
Advanced
Resear
c
h
and
Re
vie
ws
,
v
ol.
22,
no.
3,
pp.
1568–1574,
2024,
doi:
10.30574/wjarr
.2024.22.3.1895.
[19]
L.
Li,
P
.
Shi,
X.
Fu,
P
.
Chen,
T
.
Zhong,
and
J.
K
ong,
“Three-Dimensional
T
radeof
fs
for
Consensus
Algorithms:
A
Re
vie
w
,
”
IEEE
T
r
ansactions
on
Network
and
Service
Mana
g
ement
,
v
ol.
19,
no.
2,
pp.
1121–1140,
2022,
doi:
10.1109/TNSM.2021.3133933.
[20]
D.
S.
K
umar
and
K.
Jayasurya,
“Fintech’
s
Hidden
Hand:
Ho
w
P
ayP
al
Reshaped
the
Financial
W
orld,
”
2025.
Indonesian
J
Elec
Eng
&
Comp
Sci,
V
ol.
42,
No.
3,
June
2026:
892–901
Evaluation Warning : The document was created with Spire.PDF for Python.
Indonesian
J
Elec
Eng
&
Comp
Sci
ISSN:
2502-4752
❒
901
[21]
E.
Androulaki
et
al.
,
“Hyperledger
F
abric:
A
Distrib
uted
Operating
System
for
Permissioned
Blockchains,
”
in
Pr
oceedings
of
the
Thirteenth
Eur
oSys
Confer
ence
(Eur
oSys
’18)
,
Article
No.
30,
pp.
1–15,
A
CM,
2018,
doi:
10.1145/3190508.3190538.
[22]
D.
V
uji
ˇ
ci
´
c,
D.
Jagodi
´
c,
and
S.
Randi
´
c,
“Blockchain
T
echnology
,
Bitcoin,
and
Ethereum:
A
Brief
Ov
ervie
w
,
”
in
Pr
oceedings
of
the
17th
International
Symposium
INFO
TEH-J
AHORIN
A
,
East
Saraje
v
o,
Bosnia
and
Herze
go
vina,
pp.
1–6,
2018,
doi:
10.1109/IN-
FO
TEH.2018.8345547.
[23]
A.
Y
ak
o
v
enk
o,
“Solana:
A
Ne
w
A
rchitecture
for
a
High
Performance
Blockchain,
”
white
paper
,
v
ersion
0.8.13,
2018.
BIOGRAPHIES
OF
A
UTHORS
Zohra
T
emmar
obtained
from
the
Uni
v
ersity
of
Science
and
T
ec
hnology
of
Oran,
Mo-
hamed
Boudiaf
(UST
O-MB),
Algeria,
her
License
de
gree
in
computer
science
in
2023
and
her
Mas-
ter’
s
de
gree
in
Netw
orks
and
Distrib
uted
Systems
in
2025.
In
2025,
she
joined
the
Department
of
Computer
Science
at
UST
O-MB,
where
she
currently
serv
es
as
a
temporary
teacher
.
Her
main
research
areas
are
distrib
uted
systems,
blockchain
technology
,
consensus
mechanisms,
and
smart-
contract–based
collaborati
v
e
tourism
systems,
which
aligns
with
her
Master’
s
thesis
on
optimizing
a
decentralized
tourism
platform
using
blockchain.
She
can
be
contacted
at:
zahratemmar@gmail.com.
Asmaa
Boughrara
obtained
from
the
Uni
v
ersity
of
Science
and
T
echnology
of
Oran,
Mohamed
Boudiaf
(UST
O-MB),
Algeria,
her
License
de
gree
in
computer
science
in
2007
and
MSc
de
gree
in
Computer
Systems
and
Netw
orks
in
2009.
She
pursued
her
PhD
de
gree
in
Computer
Systems
and
Netw
orks
from
UST
O-MB,
in
2015.
In
2016,
s
he
joined
the
Department
of
Computer
Science
at
UST
O-MB
and
became
lecture
class
B
in
2017.
Her
main
research
areas
are
distrib
uted
systems,
blockchain,
and
routing
and
switching.
She
can
be
contacted
at:
asmaa.boughrara@uni
v-
usto.dz.
Smart
contr
acts
and
a
dual
bloc
kc
hain
structur
e
for
collabor
ative
tourism
(Zohr
a
T
emmar)
Evaluation Warning : The document was created with Spire.PDF for Python.